From nobody Mon Jan 4 07:57:32 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A191A89FD for ; Mon, 4 Jan 2016 07:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 9jeiySWEIid5 for ; Mon, 4 Jan 2016 07:57:28 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0147.outbound.protection.outlook.com [65.55.169.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB671A89FA for ; Mon, 4 Jan 2016 07:57:28 -0800 (PST) Received: from CY1PR09MB0796.namprd09.prod.outlook.com (10.163.43.146) by CY1PR09MB0889.namprd09.prod.outlook.com (10.163.43.27) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 4 Jan 2016 15:57:25 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0796.namprd09.prod.outlook.com (10.163.43.146) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 4 Jan 2016 15:57:25 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0361.006; Mon, 4 Jan 2016 15:57:25 +0000 From: "Sriram, Kotikalapudi" To: "mlepinski@ncf.edu" , "david@mandelberg.org" , "sra@hactrn.net" Thread-Topic: comments on draft-ietf-sidr-bgpsec-protocol-14 -- data covered by signature Thread-Index: AQHRRwiaKZj5aeewW0Sem5gv/VTpvw== Date: Mon, 4 Jan 2016 15:57:25 +0000 Message-ID: References: <20151208204116.30503.33351.idtracker@ietfa.amsl.com> In-Reply-To: <20151208204116.30503.33351.idtracker@ietfa.amsl.com> 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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.222.187] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0796; 5:y2YGb7IIXgaK3ddTUgJCQ7H1W2uYOvgELc/u82BKfa2JY8+GmeOV6muwpl06SgHcRjui4jVgcZ2nIIx5JolUIjWaiHTBrAH7umpI5TA/JKMjfnXiigJVE8WBL2ghEnIfcMWdcfDnv451fefUV9S8eg==; 24:FyWHdO1AMvtHpZaERjPAuuMmZF7i6d2VGqvytOZde0hAfwGQQzZk9k6zgnQEeC+QGUC/pxyJ5s1zLaHgxz0eh85NejB/sk5qfIV8ugAZ1uk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0796; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR09MB0796; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0796; x-forefront-prvs: 08118EFC2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(164054003)(586003)(101416001)(106356001)(5008740100001)(77096005)(50986999)(1096002)(102836003)(229853001)(81156007)(2900100001)(5002640100001)(86362001)(99286002)(106116001)(5001960100002)(33656002)(105586002)(15975445007)(76176999)(54356999)(189998001)(5003600100002)(230783001)(5001770100001)(10400500002)(11100500001)(76576001)(3846002)(2501003)(4326007)(40100003)(97736004)(66066001)(1220700001)(6116002)(2950100001)(2201001)(122556002)(87936001)(92566002)(2171001)(5004730100002)(19580395003)(74316001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0796; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2016 15:57:25.3602 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0796 X-Microsoft-Exchange-Diagnostics: 1; CY1PR09MB0889; 2:f9Tu5ljVvozAdI97m9cButQgZN5Ui1a9MfS5uGhaRWkYRUsAW11+Om/KKi3V9Ty5Y+mTEQBmwGYAyl40Js67KcRlfzmbPIV4fj5qPo+g+6EaMCGUxuYA/YWD0mL9yEiaYYq8ybN43NucK9eeUixKhg==; 23:rBxHAUGaTMXDE8Iq8bqFaq24UjR0jeGAOXZhHBc+z4MkA4y8dkVpeTZ0DzgTD2DyPCV+2qHE6b0O5qvaLAlT9ES1iWJSSJi28a+MOaHEM5u+u4/DLIhHWOIurHtAeIRN6FbDKe3QBwHnvMNZVuN6xpPq1Xg2ki6qTxpHBRLvJqAr9A7S1HT9/QfXHktbPbGx X-OriginatorOrg: nist.gov Archived-At: Cc: "sidr@ietf.org" Subject: [sidr] comments on draft-ietf-sidr-bgpsec-protocol-14 -- data covered by signature X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 15:57:31 -0000 Happy New Year! I have given it (version 14) a complete read. Thanks, Matt, once gain for a= ll your efforts. My comments are split over two posts.=20 This is the first post that seeks to clarify a technical point.=20 My second post will have comments/suggestions to help improve=20 the clarity/presentation in the document, and also lists some typos and nit= s. The following were the three possibilities for a protocol change to address= the=20 problem that David identified:=20 1. Signature protects the Target ASN, {ASN, pCounts, Flags} of the signer,= =20 Previous Secure_Path, and {AFI, SAFI, NLRI}. =20 2. Signature protects all of the data in #1 and the most recently added Sig= nature_Segment=20 (i.e. that of the eBGPsec speaker from whom the update was received). 3. Signature protects all of the data in #1 and the Previous Signature_Bloc= k=20 (i.e. all previous Signature_Segments).=20 David initially proposed #1. http://www.ietf.org/mail-archive/web/sidr/current/msg07258.html =20 Following on that, Rob made a case for #2. http://www.ietf.org/mail-archive/web/sidr/current/msg07261.html =20 I don=92t think #3 was discussed in that thread. Nevertheless it is a solut= ion candidate. #3 is what Matt has included in the revised draft. The relative merits of #2 and #3 are worth a little discussion. =20 =20 One thing to note is that ECDSA-P256 signature length is about 72 octets (including DER (ASN1) format overheads); plus 22 octets for SKI and Sig len= gth. So a total of 94 octets of additional data (per signature) is to be include= d=20 in the hashed data at BGPsec routers. In the case of #2, the *additional data* to be hashed would be a constant a= t 94 octets, (independent of the AS path length), while in the case of #3, =20 it would be variable given by #AS (i.e. previous path length) x 94 octets. So, for example, 940 octets more (for #3 over #2) if the previous AS path l= ength is 10. Is this of concern? One good thing is that the Signature_Segments to be add= ed to the hashed data are adjacent (that helps in consideration of #3).=20 Adjacency helps with lowering # CPU cycles consumed for marshaling the data= for hash (for #3). We have preliminary measurement data which shows that the performance for=20 SHA-256 hash operations on Intel NUC 3GHz (single threading) is as follows: (we will be conducting this study also on a 3.5 GHz server with a lot more = RAM): Hash input data size | time per SHA-256 hash operation | hash operation = speed | =20 50 octets | 0.34 usec | 2,923,662 hash ops/s 100 octets | 0.58 usec | 1,716,556 hash ops/s=20 500 octets | 2.02 usec | 493,969 hash ops/s 1000 octets | 3.93 usec | 254,462 hash ops/s 5000 octets | 17.21 usec | 58,109 hash ops/s (Averaged over 1000 iterations; usec =3D microseconds) For a long previous-AS-path length of 10, with the choice of #2,=20 we=92ll be in 300 octets ballpark for hashed data size, and with the choice of #3, we=92ll be around 1200 octets ballpark for hashed da= ta size. So, to me it looks like #3 choice does not have a significant penalty over #2 choice in terms the performance of hashing operations for the range of hashed data sizes of our interest. It is true that the hash processing time more than doubles for #3 compared = to #2 in the=20 hash data size ranges of interest. However, since all other BGPsec update p= rocessing=20 is likely to dominate over the hash processing time, the concern with regar= d to=20 hash performance may not be huge when comparing #3 with #2. The adjacency assumption of the multiple Signature_Segments for hashing is = important for #3, and should hold (hopefully) in the implementations. =20 Your thoughts/inputs on the merits/trade-offs of #2 vs. #3? Please share th= em. Thank you. Sriram From nobody Mon Jan 4 08:40:47 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB7B1A8A75 for ; Mon, 4 Jan 2016 08:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 8EHbqAq1rZ72 for ; Mon, 4 Jan 2016 08:40:44 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0120.outbound.protection.outlook.com [65.55.169.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6941A8A66 for ; Mon, 4 Jan 2016 08:40:43 -0800 (PST) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0795.namprd09.prod.outlook.com (10.163.43.145) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 4 Jan 2016 16:40:41 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0361.006; Mon, 4 Jan 2016 16:40:41 +0000 From: "Sriram, Kotikalapudi" To: "mlepinski@ncf.edu" Thread-Topic: comments on draft-ietf-sidr-bgpsec-protocol-14 -- editorial Thread-Index: AQHRRw6mDXi/lVbXT0eH1b0rEMlVpw== Date: Mon, 4 Jan 2016 16:40:41 +0000 Message-ID: References: <20151208204116.30503.33351.idtracker@ietfa.amsl.com>, In-Reply-To: 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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.222.187] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0795; 5:S7U+BJ9oq0I+MFP9Qx4Notn1axj4dncpULwhdRBt0/anj3Myglgkey7PkaNAujxUklKrA319SbvH/rxC2i+aLYAADGo030pLHtC1y3ZWfZ/18XcSakidEdZRo42Ybdx6JtSuzvtkfEtcP6F5Y/4bNQ==; 24:bSn7G091uo79MS4UIB0GjbAbqSR1JSeNVmaJXk7kv0vds2/a+JfVWJ0FZ98nDfUY8jELjsUlG4j0uhG8SZ7xdI30ZtNKv81cMELCKWH9fo4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0795; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR09MB0795; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0795; x-forefront-prvs: 08118EFC2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(78094002)(101416001)(11100500001)(33656002)(229853001)(76176999)(74316001)(102836003)(5003600100002)(6116002)(3846002)(40100003)(1220700001)(1096002)(122556002)(586003)(10400500002)(105586002)(99286002)(106356001)(4326007)(5001960100002)(76576001)(5008740100001)(81156007)(106116001)(2351001)(230783001)(50986999)(5002640100001)(2171001)(87936001)(1730700002)(110136002)(5004730100002)(2950100001)(189998001)(86362001)(66066001)(77096005)(92566002)(2900100001)(54356999)(97736004)(2501003)(11771555001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0795; H:CY1PR09MB0793.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2016 16:40:41.2712 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0795 Archived-At: Cc: "sidr@ietf.org" Subject: [sidr] comments on draft-ietf-sidr-bgpsec-protocol-14 -- editorial X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 16:40:46 -0000 Matt, I hope you find these comments helpful. Comments/Suggestions to help improve clarity/presentation: -----------------------------------------------------=AC-------------------= ------- Page 3, 3rd para: add [20] next to [19]; both are relevant references. Page 5, 1st para: s/=85for the same AFI combination=85/=85for the same AFI = =85/ Page 8, 1st para: s/(i.e., the number of AS numbers in the path)/ (i.e., the number of distinct AS numbers in the path)/ Page 14, 1st para: At the end of this para, within the parentheses, I sugge= st adding:=20 See Section 4.4 for an algorithm for reconstruction of AS_PATH attribute. Page 15: 2nd last para:=20 s/=85populated with the length (in octets) of the Signature field/ =85populated with the length (in octets) of the value in the Signature fiel= d/ Page 17, 2nd para from bottom:=20 s/ =85if the next most recently added Secure_Path segment=85/ =85if the immediately following Secure_Path segment=85/ Note that "next most recently added Secure_Path segment" connotes=20 "immediately preceding Secure_Path segment" (i.e. going backward in time).= =20 It seems to me, that is not what was intended here. Page 18, 1st para: At the end, add the following: (see Section 5.2). Page 18, please append the following at the end of the 1st para: Before attempting to reconstruct an AS_PATH for the purpose of forwarding=20 an unsigned (non-BGPsec) update to a peer, a BGPsec speaker MUST perform the basic integrity checks listed in Section 5.2 to ensure that the= received BGPsec update is properly formed. Page 19, last para: s/ via the RTR protocol/ via the RPKI-to-Router (RTR) p= rotocol [15]/ Pages 20-21, Section 5.1: The mention of ROA and the second bullet item (to= p of page 21)=20 are not needed here, because ROA is not used in BGPsec validation (origin v= alidation does that). Page 22, last para: "If there is no Signature_Block corresponding to an algorithm suite that the BGPsec speaker supports, then the BGPsec speaker MUST treat the update message in the same manner that the BGPsec speaker would treat an (unsigned) update=85" Note that the former (without supported algorithm suite) is not the same as unsigned, so they cannot be treated in the same manner. So I think it would be more precise to say it the following way: "If there is no Signature_Block corresponding to an algorithm suite that=20 the BGPsec speaker supports, then the BGPsec speaker MUST=20 process the update message as follows: First, convert the Secure_PATH attribute to AS_PATH attribute, and then treat the update as if it was received unsigned (non-BGPsec)." Page 23, in the Figure: s/Rest of Secure_Path/Preceding portion of Secure_P= ath/ Note that "Rest of Secure Path" implies Secure_Path segments before and aft= er the current one.=20 Minor modifications in the text on page 24 also need to be made, wherever "Rest of Secure_Path" is mentioned.=20 Page 25 (1st full para): "If at least one Signature_Block is marked as 'Valid', then the validation algorithm terminates and the BGPsec update message is deemed to be 'Valid'. (That is, if a BGPsec update message contains two Signature_Blocks then the update message is deemed 'Valid' if the first Signature_Block is marked 'Valid' OR the second Signature_Block is marked 'Valid'.)" I think we cannot say here "=85BGPsec update message is deemed to be 'Valid= '." This document only specifies validation for Signature_Block (or Secure_Path= ). It is up to the operator to combine the result of RFC6811 (origin validatio= n) with the results of this document (path validation) to decide about the overall validity of the BGPsec update message. =20 So, instead of "is deemed to be 'Valid' ", should we say "is deemed to be '= Path Valid' "? Page 27, 1st paragraph (below the bullet):=20 "That is, the recipient of a valid BGPsec Update message is assured that the Secure_Path portion of the BGPsec_Path attribute corresponds to a sequence of autonomous systems who have all agreed in principle to forward packets to the given prefix along the indicated path. (It should be noted that BGPsec does not offer any guarantee that the data packets would flow along the indicated path; it only guarantees that the BGP update conveying the path indeed propagated along the indicated path.)" I find the first sentence problematic. In essence, it contradicts the secon= d sentence. The first sentence says BGPsec assures something about the data plane. The second sentence says BGPsec does not guarantee anything about the data = plane! I would reword the first sentence as follows: "That is, the recipient of a valid BGPsec update message is assured that=20 the update propagated via the sequences ASes listed in the Secure_Path=20 portion of the BGPsec_Path attribute." Page 27, 1st paragraph (below the bullet), in the last sentence: s/ the recipient is assured that this path terminates.../ the recipient is = assured, due to origin validation, that this path terminates=85/ Note: I suggest this wording because BGPsec does not provide this=20 particular assurance; origin validation does. Page 30, 2nd para (last para of Section 7.4):=20 This appears to be a carryover from v.13 draft since it refers to old Secti= ons 4.1 and 4.2.=20 It is also worth noting that the extremely unlikely attack=20 being mentioned here is made even more unlikely due to=20 more data that needs to be signed over at the second AS (based on this v-14= draft). =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Typos, Nits: --------------- Page 12, 3rd para: s/=85update message has not been that has not successful= ly validated/ =85update message has not been successfully validated/ Page 15, 1st para: same sentence twice in the same para =85=20 "the Target AS Number is the AS to whom the BGPsec speaker intends to send = the update message" Similar sentence appeared earlier in the same para at bottom of page 14). Page 16, 1st para: The following phrase is repeated twice in the same para: "when a confederation member sends a BGPsec update message to a peer=20 that is a member of the same confederation" Page 16, 1st para: The following phrase is repeated twice in the same sente= nce (last sentence): "in a non-BGPsec update message" Page 25, 2nd para in Section 6.1: s/a mandatory algorithm suites document will be created/ =20 a mandatory algorithm suites document exists/=20 References: [9] should have date of November 2015 (it shows Nov. 2014). Page 17 and p.22: s/RFC WXYZ/RFC 7606/ Global substitution: s/AS_Path/AS_PATH/g Global substitution: s/BGPSEC/BGPsec/g Thank you. Sriram From nobody Thu Jan 7 09:18:12 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD981A90F9 for ; Thu, 7 Jan 2016 09:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 iPeEncAHmXXS for ; Thu, 7 Jan 2016 09:18:09 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979FE1A90FC for ; Thu, 7 Jan 2016 09:18:09 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:49709 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aHECO-0007KZ-3x for sidr@ietf.org; Thu, 07 Jan 2016 12:18:08 -0500 From: Stephen Kent To: sidr@ietf.org References: <565617E8.4070005@bbn.com> <8FB9C3A7-0799-4CF7-80A5-7669070B3C91@ripe.net> Message-ID: <568E9DCF.3090502@bbn.com> Date: Thu, 7 Jan 2016 12:18:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 17:18:11 -0000 Geoff, > ... >> 2. How do you perform the validation of a CRL? > RFC6487 provided no guidance, and referred to RFC5280, so that is still the case. > nothing changes herre. RFC 6487 modified the validation algorithm from 5280, and stated that the revised algorithm applies to "resource certificates." A CA cert issued in the RPKI is a resource certificate. Thus to verify the signature on a CRL one must use a valid CA cert. Thus Sriram's question was, I believe, more precisely stated as how does the revised validation procedure apply to a CA cert, which is then used to verify the signature on a CRL. >> How is it similar to or different from how you validate a ROA? > There are no resources in a CRL so I presume that section 6.1 of RFC5280 is > a good procedure to follow. see comment above. >> How do you walk the certificate hierarchy in the case of a CRL validation process? >> I.e. How are the "encompassing" rules applied? > huh - Ill say it again just to be sure: CRLs have no resources. but the CA cert used to verify a CRL signature does contain resources, and that, I believe, was the issue Sriram was raising, and that my message raised. Steve From nobody Thu Jan 7 09:18:21 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE7D1A9102 for ; Thu, 7 Jan 2016 09:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 mv044exuEAMH for ; Thu, 7 Jan 2016 09:18:13 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B67E1A9100 for ; Thu, 7 Jan 2016 09:18:13 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:49710 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aHECR-0007Kc-WE; Thu, 07 Jan 2016 12:18:12 -0500 From: Stephen Kent To: Geoff Huston References: <565617E8.4070005@bbn.com> Message-ID: <568E9DD3.2040403@bbn.com> Date: Thu, 7 Jan 2016 12:18:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sidr Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 17:18:18 -0000 Geoff, Happy new year. > ... > >> Consider a cert path from a trust anchor TA, to CA1 to CA2 to an EE cert for a ROA. >> >> TA->CA 1->CA 2->ROA >> >> >> Assume the TA cert contains address space T, U, V, W, X, Y and Z. >> >> Assume the CA 1 cert contains address space T, U, V, and W. >> >> Assume the CA 2 cert contains address space V and W. >> >> Let's say that the ROA EE cert issued by CA 2 contains address space V. >> >> CA 2 is about to receive address space Z from some other ISP, so it has asked >> CA 1 to issue a new CA cert to it, in anticipation of the transfer. CA 1 agrees, >> and issues a new cert to CA 2 and that cert contains address space V and Z. > CA1 has already issued a cert with subject “CA2” and resources (V,W) - lets call this cert No 1 > > Do you mean: > > a) CA 1 issues a cert with subject “CA2” and resources (V,Z) - lets call this cert No 2 > > OR the combination of actions: > > b) CA 1 issues a SECOND cert with subject “CA2” and resources (V,Z) - lets call this Cert No 2 > AND > CA1 revokes the cert with subject “CA2” and resources (V,W) (which we call Cert No 1) I intended the second case. Chris pointed out to me in a private message that I failed to include W in this cert; my bad. I intended to have the new cert add Z to V and W. >> Now, under the assumption about what "specific resource set" means, when >> an RP tries to validate CA 2's ROA, > Now I’m confused - originally the ROA was signed by an EE cert issued by CA 2’s Cert No 1 > > so when you refer to CA 2’s ROA do you mean the ROA that was signed by an EE cert issued by CA 2’s Cert No 1, > or do you mean a new ROA signed by an EE issued by CA 2’s Cert No 2? No ROA is "signed" by any cert; a signature on a ROA (or a cert) is verified using a cert. The ROA to which I refer is issued under CA 2 (your Cert 1), and it is not new. I described the ROA when I trued to set the stage for the example: "Let's say that the ROA EE cert issued by CA 2 contains address space V." >> the "specific resource set" will be V, and >> so it will be valid, because V is in all of the certs from the TA through CA 1 >> to CA 2. Even though CA 2's cert contains Z, which is not contained >> in CA 1's cert, this will not be considered in the validation of the ROA EE cert. >> This is the desired outcome, because CA 2 has begun the process of getting its >> new address space (Z), but that process has not broken its CA cert. I assume this >> is an example of the reduced fragility that is so appealing. > So I _think_ you are assuming that there is a new ROA, signed by an EE cert issued by > the CA that has a CA cert issued by CA 1 with resources (V,Z), and evidently you are referring > to this new ROA and its new EE cert. no, it's the same ROA I defined in the intro to the example. I'll stop at this point, because the remainder of your comments are based on the assumption that this was a new ROA, which was not my intent. Sorry for the typo in the resource set for "Cert 1" and for not being more explicit in saying that the new Cert for CA 2 was issued by CA 1 as a replacement for the original CA 2 cert. Steve From nobody Sun Jan 10 11:18:50 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E6D1ACEB7 for ; Sun, 10 Jan 2016 11:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 lzGM3nsc1rGi for ; Sun, 10 Jan 2016 11:18:45 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0109.outbound.protection.outlook.com [23.103.201.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86B971ACEAD for ; Sun, 10 Jan 2016 11:18:45 -0800 (PST) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0796.namprd09.prod.outlook.com (10.163.43.146) with Microsoft SMTP Server (TLS) id 15.1.365.19; Sun, 10 Jan 2016 19:18:41 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0365.019; Sun, 10 Jan 2016 19:18:41 +0000 From: "Sriram, Kotikalapudi" To: Stephen Kent , Geoff Huston , "Tim Bruijnzeels" Thread-Topic: [sidr] Validation Reconsidered (again/again) question Thread-Index: AQHRJ76kclsFhw+pBUOxgfRVH01CoJ6uPM2AgAJQQiCAAt40AIA9I/+AgATMvzw= Date: Sun, 10 Jan 2016 19:18:41 +0000 Message-ID: References: <565617E8.4070005@bbn.com> <8FB9C3A7-0799-4CF7-80A5-7669070B3C91@ripe.net> ,<568E9DCF.3090502@bbn.com> In-Reply-To: <568E9DCF.3090502@bbn.com> 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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.218.185] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0796; 5:6LMAEz6ZSs6uPKkK9Lm9lyu3lrduafe8+lc2GuuXQSQar0iyeYmYwWsooj963MBcUuxK6bHyPC+yBeoRLGHNtWWSX2ncospQROKs+nMOvdmpbLMLS0N0R2WM2eHqUPWI63kr1dqykHIBYU93ZkXRyA==; 24:qraoVcnmgr2NgsF1pEIWhWIA6FuazrtrKjRVIuKq6Jw9I0j5UMVqhldQkvtbxRNU9zkr00Q5SsVCNDf7QLgVzoIG4ldEPMaXGCz5mIQlt9g= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0796; x-ms-office365-filtering-correlation-id: 81c493bd-9d62-4d81-c419-08d319f2da01 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:CY1PR09MB0796; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0796; x-forefront-prvs: 0817737FD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(77096005)(15975445007)(586003)(102836003)(5001960100002)(106116001)(5001770100001)(99286002)(189998001)(5002640100001)(3846002)(1220700001)(11100500001)(93886004)(106356001)(1096002)(105586002)(81156007)(86362001)(76576001)(5004730100002)(122556002)(54356999)(2950100001)(40100003)(19580395003)(10400500002)(5003600100002)(66066001)(97736004)(2906002)(2900100001)(6116002)(76176999)(33656002)(92566002)(50986999)(74316001)(87936001)(5008740100001)(101416001)(4326007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0796; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2016 19:18:41.5638 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0796 Archived-At: Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] Validation Reconsidered (again/again) question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 19:18:48 -0000 Steve, >but the CA cert used to verify a CRL signature does contain resources, >and that, I believe, was the issue Sriram was raising,=20 >and that my message raised. To be fair, Geoff did respond to my question: http://www.ietf.org/mail-archive/web/sidr/current/msg07453.html =20 He said: =93I would=92ve thought that if you can establish a chain of=20 Issuer / subject certs that connect a chosen Trust Anchor to the CA that issued the CRL then you have a sound reason to accept the CRL. Given that the CRL has no resources there does not=20 seem to be any resource attribute test that can be applied here.=94 So, as I understand it now, when validating a ROA or a CRL, the first basic step (Step #1) is this:=20 (Geoff/Tim: This is a description based on my understanding; please correct me if I got it wrong.) Step #1:=20 Gather the relevant resource CA certs in the cert-path:=20 C0, C1, C2, ..., Cn, where C0 is the TA=92s cert and Cn is the final resource holder=92s cert who created the ROA or issued the CRL. Before saying anything about the ROA or the CRL validity, first perform a basic check to see if *cert-path is Valid*. =20 The given *cert-path is Valid* if the following holds: the signature on cert Ci is Valid when verified=20 with the public key associated with cert C(i-1), for all i in 1 <=3D i <=3D= n.=20 In this basic validation process, no consideration is given to the resources contained in the certs. So at this step in the algorithm, it is not checked whether=20 the resources contained in the certs are =93encompassing=94 or not. This step only cares about verifying the chain of issuer/subject=20 relationships (the successive issuers=92 signatures on the certs). (Proceed to Step #2 if the *cert-path is Valid*.) Step #2 (in the case of a ROA):=20 (Recall that the holder of Cn issued the ROA) The ROA is Valid if all of the following conditions hold: (a) The signature on the EE cert is Valid (verified=20 with the public key associated with Cn). (b) The signature on the ROA is valid (verified with the public key associated with the EE cert). (c) The prefix resources in the ROA exactly match the=20 resources listed in the EE cert. (d) All the prefix resources in the ROA are contained in the intersection of the resources listed=20 in the set {C0, C1, ..., Cn}. Step #2 (in the case of a CRL):=20 (Recall that the holder of Cn issued the CRL) The CRL is Valid if all the following conditions hold: (a) The certificate(s) being revoked in the CRL=20 is (are) certificates that were issued earlier=20 by the subject (holder) of Cn.=20 (b) The signature on the CRL is Valid (verified with=20 the public key associated with Cn).=20 (Note: No need to look into the list of resources listed in Cn for CRL validation. Cn can issue a cert C(n+1) and later revoke it at will by issuing a CRL. When the CRL is received, for its validation purpose, we don=92t need to=20 look at what resources are listed in the revoked cert C(n+1) and their relation with the resources listed in cert Cn. Because the resource cert that is being CRL=92ed=20 is meant to be discarded.)=20 Sriram =20 From nobody Tue Jan 12 18:13:27 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EEF1B2BD6; Tue, 12 Jan 2016 18:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 pYzBin1-Lkwf; Tue, 12 Jan 2016 18:13:24 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 75FC51B2BD5; Tue, 12 Jan 2016 18:13:24 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 15EE5180011; Tue, 12 Jan 2016 18:12:36 -0800 (PST) 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 Message-Id: <20160113021236.15EE5180011@rfc-editor.org> Date: Tue, 12 Jan 2016 18:12:36 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, sidr@ietf.org, rfc-editor@rfc-editor.org Subject: [sidr] RFC 7730 on Resource Public Key Infrastructure (RPKI) Trust Anchor Locator X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 02:13:26 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7730 Title: Resource Public Key Infrastructure (RPKI) Trust Anchor Locator Author: G. Huston, S. Weiler, G. Michaelson, S. Kent Status: Standards Track Stream: IETF Date: January 2016 Mailbox: gih@apnic.net, weiler@tislabs.com, ggm@apnic.net, kent@bbn.com Pages: 8 Characters: 17672 Obsoletes: RFC 6490 I-D Tag: draft-ietf-sidr-rfc6490-bis-05.txt URL: https://www.rfc-editor.org/info/rfc7730 DOI: http://dx.doi.org/10.17487/RFC7730 This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). This document obsoletes RFC 6490 by adding support for multiple URIs in a TAL. 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/rfc.html 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 Jan 14 05:42:37 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6921B34FE for ; Thu, 14 Jan 2016 05:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_64=0.6, RP_MATCHES_RCVD=-0.001] autolearn=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 O8_tNVYHrpwr for ; Thu, 14 Jan 2016 05:42:35 -0800 (PST) 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 DA53F1B34FD for ; Thu, 14 Jan 2016 05:42:34 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1aJiAa-0007d6-1x for sidr@ietf.org; Thu, 14 Jan 2016 14:42:33 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-12.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1aJiAZ-0007Uw-SS; Thu, 14 Jan 2016 14:42:31 +0100 From: Tim Bruijnzeels Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jan 2016 14:42:31 +0100 To: sidr Message-Id: <47AD8396-3D52-4FCE-8AC2-7EFBC94C94E5@ripe.net> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719d73dd0423cbfc500765885fd5397f793 Archived-At: Subject: [sidr] Using RRDP links in the RIPE NCC repository X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 13:42:36 -0000 Hi all, Just a heads up that we have started to include RRDP SIAs as in the RIPE = NCC RPKI certificates. We are using a cloud provider to host the = publication server and CDN - but I am not sure it's appropriate to name = companies on this list ;). It shouldn't affect any recent validators - = recent versions of rcynic, RPSTIR and the RIPE NCC RPKI Validator all = ignore the additional URIs. As discussed at the last two IETFs, we = figured it would be safe to start using this as a beta service. However we have had one report from JPNIC who were using an older RP = tool that had an issue with this. If you see similar problems you may = want to upgrade your RP tools. If you want to help us test the new protocol, our latest validator = supports it - but you have to enable it in config, by setting the = following in the rpki-validator.conf: > prefer.rrdp =3D true Our validator can be downloaded here: = https://www.ripe.net/manage-ips-and-asns/resource-management/certification= /tools-and-resources But of course we are also very interested in feedback from other RP = software. Please let us know if you have any question or comment, or find any = issues. Cheers, Tim= From nobody Fri Jan 29 06:54:45 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A064F1A6FB1; Fri, 29 Jan 2016 06:54:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160129145444.24119.53968.idtracker@ietfa.amsl.com> Date: Fri, 29 Jan 2016 06:54:44 -0800 Archived-At: Cc: sidr@ietf.org, sidr-chairs@ietf.org, sandy@tislabs.com Subject: [sidr] sidr - New Meeting Session Request for IETF 95 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 14:54:44 -0000 A new meeting session request has just been submitted by Sandra L. Murphy, a Chair of the sidr working group. --------------------------------------------------------- Working Group Name: Secure Inter-Domain Routing Area Name: Routing Area Session Requester: Sandra Murphy Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 90 Conflicts to Avoid: First Priority: opsec idr grow saag rtgwg rtgarea Second Priority: dane i2rs isis spring trill Third Priority: trans Special Requests: ---------------------------------------------------------