From nobody Mon Aug 4 13:42:41 2014 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 B3F811A0308 for ; Mon, 4 Aug 2014 13:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.234 X-Spam-Level: ** X-Spam-Status: No, score=2.234 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 mpqhb1pXkb9K for ; Mon, 4 Aug 2014 13:42:38 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5DC1A02F4 for ; Mon, 4 Aug 2014 13:42:37 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.01,800,1400040000"; d="scan'208";a="434185406" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 04 Aug 2014 16:42:22 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Mon, 4 Aug 2014 16:42:36 -0400 From: "George, Wes" To: Stephen Kent , "sidr@ietf.org" Date: Mon, 4 Aug 2014 16:42:35 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt Thread-Index: Ac+wJJ+nYAer4wgZRM2PK2NDievCUQ== Message-ID: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> In-Reply-To: <53DAA101.8020305@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/-4ohwu35eKDWlExOmhpg31-aT4c Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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 Aug 2014 20:42:39 -0000 TGF0ZSB0byB0aGUgZGlzY3Vzc2lvbiBiZWNhdXNlIEkgbmVlZGVkIHRvIGhhdmUgY3ljbGVzIHRv IHJlYWQgYW5kIHRoaW5rDQphYm91dCB0aGlzIGRyYWZ0Li4uDQoNCg0KT24gNy8zMS8xNCwgNDow MyBQTSwgIlN0ZXBoZW4gS2VudCIgPGtlbnRAYmJuLmNvbT4gd3JvdGU6DQoNCj5UZXJyeSBoYXMg cmVtaW5kZWQgdXMgdGhhdCwgZXZlbiBpZiBzdWNoIGFjY2lkZW50cyBvY2N1ciwgdGhlIHdvcmxk IGRvZXMNCj5ub3QgZW5kLCBhdA0KPmxlYXN0IHdydCBvcmlnaW4gdmFsaWRhdGlvbi4gVGh1cywg Zm9yIHRoZSBjdXJyZW50IHNldCBvZiBTSURSIFJGQ3MsIHRoZQ0KPmRhbWFnZSB0aGF0DQo+d291 bGQgb2NjdXIgaXMgbm90IG5lYXJseSBzbyBncmVhdCBhcyBzb21lIGhhdmUgc3VnZ2VzdGVkOyB1 bnRpbCB0aGUNCj5lcnJvciBpcyBmaXhlZCAod2hpY2gNCj5vbmUgd291bGQgcHJlc3VtZSB3b3Vs ZCBiZSBmYWlybHkgcXVpY2tseSksIG9yaWdpbiB2YWxpZGF0aW9uIHdvdWxkDQo+dHJlYXQgdGhl IGFmZmVjdGVkDQo+cm91dGVzIGFzIG5vIHdvcnNlIHRoYW4gdGhleSBhcmUgdHJlYXRlZCB0b2Rh eS4NCg0KV0ddIE1heWJlIEknbSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IEknbSBub3Qgc3VyZSBJ IGFncmVlIHdpdGggdGhpcw0KY2hhcmFjdGVyaXphdGlvbi4gVGhpcyBpcyBwcm9iYWJseSB0cnVl IGZvciByb3V0ZXMgdGhhdCB0cmFuc2l0aW9uIGZyb20NClZhbGlkIHRvIFVua25vd24sIGJ1dCBu b3QgaWYgdGhleSBhcmUgYWN0dWFsbHkgZm91bmQgdG8gYmUgSW52YWxpZCwgd2hpY2gNCmlzIHdo YXQgSSB1bmRlcnN0YW5kIHdvdWxkIGJlIHRoZSByZXN1bHQgb2YgdGhlIHByb2JsZW0gZGlzY3Vz c2VkIGluIHRoaXMNCmRyYWZ0IC0gaW52YWxpZCBjZXJ0cyA9IGludmFsaWQgcm91dGVzLiBXaGls ZSBwb2xpY3kgaXMgdWx0aW1hdGVseSBhIGxvY2FsDQptYXR0ZXIsIGluIDcxMTUgd2UgcmVjb21t ZW5kIGRyb3BwaW5nIGludmFsaWRzIGR1ZSB0byB0aGUgZmFjdCB0aGF0IGl0DQppc24ndCBwb3Nz aWJsZSB0byBkZXByZWYgYW55IHJvdXRlcyBlbm91Z2ggdG8gZW5zdXJlIHRoYXQgdGhleSBhcmUg bmV2ZXINCnVzZWQgaWYgdGhleSBhcmUgbW9yZSBzcGVjaWZpYyB0aGFuIGEgdmFsaWQgb3IgdW5r bm93biByb3V0ZSB3aXRoIGENCmNvbXBhcmFibHkgaGlnaGVyIGxvY2FsIHByZWYuIFVubGVzcyB3 ZSdyZSBjaGFuZ2luZyB0aGF0IGd1aWRhbmNlLCAiJQ0KTmV0d29yayBub3QgaW4gdGFibGUiIGlz IHdvcnNlIHRoYW4gdGhleSdkIGJlIHRyZWF0ZWQgdG9kYXkuDQoNCkRlcGxveWluZyBTSURSIE9W IGlzIGFib3V0IHJpc2sgdnMgcmV3YXJkLCBpLmUuIEhvdyBtdWNoIGJlbmVmaXQgZG8gSSBnYWlu DQppbiB0ZXJtcyBvZiB3aGF0IG91dGFnZXMgKGF0dGFjayB2ZWN0b3JzKSBJJ20gcHJvdGVjdGlu ZyBteXNlbGYgYW5kIG15DQpjdXN0b21lcnMgYWdhaW5zdCB2cyB3aGF0IHJpc2sgdGhlIHNhbWUg cGFydGllcyBpbmN1ciBmb3IgZXhwZXJpZW5jaW5nDQpvdGhlciBvdXRhZ2VzIHRoYXQgb25seSBl eGlzdCBpZiBJIGFtIGRlcGxveWluZyBPVi4gVGhlIHBvc3NpYmlsaXR5IG9mDQpyb3V0ZXMgYmVp bmcgaW52YWxpZGF0ZWQgYW5kIGRyb3BwZWQgb24gYWNjb3VudCBvZiBhIGJvdGNoZWQgY2VydCBv dmVybGFwDQpvciBtaWdyYXRpb24gcHV0cyB0aGlzIHNxdWFyZWx5IG9uIHRoZSB3cm9uZyBzaWRl IG9mIHRoZSByaXNrL3Jld2FyZA0KYmFsYW5jZS4NCg0KVGhhbmtzDQoNCldlcyBHZW9yZ2UNCg0K DQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1l IFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdl ZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGlt ZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3Ug YXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24s IGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2Yg YW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5k IG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkg ZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBw cmludG91dC4NCg== From nobody Mon Aug 4 14:47:46 2014 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 DB3DF1A0342 for ; Mon, 4 Aug 2014 14:47:44 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 cEFO66WdfR5M for ; Mon, 4 Aug 2014 14:47:43 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646B31A0343 for ; Mon, 4 Aug 2014 14:47:43 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 8DB9D28B0072; Mon, 4 Aug 2014 17:47:42 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 85A091F8032; Mon, 4 Aug 2014 17:47:42 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_3B1CB4A0-3B76-4477-811B-53DFBA956D30"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Mon, 4 Aug 2014 17:47:42 -0400 Message-Id: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> To: "George, Wes" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/qqD-fevuYtEeEiFvq6y0qDasTx4 Cc: "sidr@ietf.org" , Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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 Aug 2014 21:47:45 -0000 --Apple-Mail=_3B1CB4A0-3B76-4477-811B-53DFBA956D30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 speaking as a regular ol' member On Aug 4, 2014, at 4:42 PM, "George, Wes" = wrote: > Late to the discussion because I needed to have cycles to read and = think > about this draft... >=20 >=20 > On 7/31/14, 4:03 PM, "Stephen Kent" wrote: >=20 > This is probably true for routes that transition from > Valid to Unknown, but not if they are actually found to be Invalid, = which > is what I understand would be the result of the problem discussed in = this > draft - invalid certs =3D invalid routes.=20 Well=85. invalid EE certs =3D invalid ROA (for the most part - there's = operational consideration about not removing an EE cert if a repository = is unavailable, I suppose) An invalid ROA does not necessarily mean an invalid route. If there is no other covering ROA, then a BGP route for that prefix = becomes unknown, as Terry pointed out. If there is another ROA which covers the same prefix, then a route may = be invalid -- if no covering ROA authorizes the ASN that the invalidated = ROA mentions. --Sandy, speaking as a regular ol' member --Apple-Mail=_3B1CB4A0-3B76-4477-811B-53DFBA956D30 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT3/9+AAoJEHplpQeet0IZuPEP/1kgUZ/1eoD01T2y8Z341FqP J1wt48BmppgJbCHR4q0O7+6jDPcX5YYeKwVhSxQXZ8b3qpxipMrv5s7iUnNqZEqk 1qXZQ7s5Qx9elzWCMdBFGpNbE8wXzjjOcNvKdqy5jLhKDWQy6bPkn3n0A84hWX1E RZrA/i8ZvAfO7FaJxA7y7tzw3IJDVN0u69uUHvfFKPzoLay03GXlF+qIEt06sh6k EbUyPCAWStCZaZtwWFTmPBpbFTokavRlO8N8IVW0jkY7zIqzFwnztX2209lWQCXl So/9FTrxKgmtRlIAv3n6vqy8f8H4hwg0uGK0ZGgJfn/SCW0iSiXUWDOPVWY/2Tro GNggLc+QsQh2n6wVfD+lT+QzDbmC4TCMqTHFJ5YOe+jy9niDQCbKahJwFKbuqdw+ dY+VCO4N99Qc0QlR99ue8TvMTnGkJlGRVLMz7vzmcfsVEsuP5C7XG2eNuCtHhAiP mfNecsqj0cxNRatkrJog7cD5kp4GUybNlv4QLlTehERsJp37UjGJtpG70TMkNUn+ e87ZpHIhq51IzQ1xyMabvR6/T32xzGg5mKfceD57v/U34ENI6N/HIkkbwXMv9sxN hl5KqhNIXM5W9UayKF2VhnP3x0Oe4TPSJ0Nh1Hi1POp5/Co32lPPGGF7xnbB0+LR 78+xO8FE6JbhDJ7c03ka =I3uJ -----END PGP SIGNATURE----- --Apple-Mail=_3B1CB4A0-3B76-4477-811B-53DFBA956D30-- From nobody Tue Aug 5 08:51:22 2014 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 A19611B2A3C for ; Tue, 5 Aug 2014 08:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 Fz_0XhNxs_15 for ; Tue, 5 Aug 2014 08:51:20 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id E82F11B2A28 for ; Tue, 5 Aug 2014 08:51:19 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.01,805,1400040000"; d="scan'208";a="435683051" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 05 Aug 2014 11:51:01 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 5 Aug 2014 11:51:19 -0400 From: "George, Wes" To: Sandra Murphy Date: Tue, 5 Aug 2014 11:51:17 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt Thread-Index: Ac+wxRhxxmLnt3lORXOIWiDWqNuhyw== Message-ID: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/aSeqV3gIAX3QmrZM0QVkaKP5i94 Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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: Tue, 05 Aug 2014 15:51:21 -0000 DQpPbiA4LzQvMTQsIDU6NDcgUE0sICJTYW5kcmEgTXVycGh5IiA8c2FuZHlAdGlzbGFicy5jb20+ IHdyb3RlOg0KDQo+QW4gaW52YWxpZCBST0EgZG9lcyBub3QgbmVjZXNzYXJpbHkgbWVhbiBhbiBp bnZhbGlkIHJvdXRlLg0KPg0KPklmIHRoZXJlIGlzIG5vIG90aGVyIGNvdmVyaW5nIFJPQSwgdGhl biBhIEJHUCByb3V0ZSBmb3IgdGhhdCBwcmVmaXgNCj5iZWNvbWVzIHVua25vd24sIGFzIFRlcnJ5 IHBvaW50ZWQgb3V0Lg0KPg0KPklmIHRoZXJlIGlzIGFub3RoZXIgUk9BIHdoaWNoIGNvdmVycyB0 aGUgc2FtZSBwcmVmaXgsIHRoZW4gYSByb3V0ZSBtYXkgYmUNCj5pbnZhbGlkIC0tIGlmIG5vIGNv dmVyaW5nIFJPQSBhdXRob3JpemVzIHRoZSBBU04gdGhhdCB0aGUgaW52YWxpZGF0ZWQgUk9BDQo+ bWVudGlvbnMuDQoNCldHXSBJJ20gb25jZSBhZ2FpbiBiaXR0ZW4gYnkgYW4gaW5jb21wbGV0ZSB1 bmRlcnN0YW5kaW5nIG9mIHRoZSB3YXkgdGhhdA0KdGhlIFBLSSBpbnRlcmFjdHMgd2l0aCB0aGUg cm91dGluZyBzaWRlLiBTaWdoLiBUaGF0IG1ha2VzIG1vcmUgc2Vuc2UsIGJ1dA0Kc2luY2UgSSBo YXZlIG9mdGVuIHZvbHVudGVlcmVkIHRvIGJlICJuZXcgZ3V5IHdobydzIG5vdCBhbiBSUEtJIGV4 cGVydCINCnRodXMgc2VydmluZyBhcyB0aGUgY2FuYXJ5IGluIHRoZSBjb2FsIG1pbmUgZm9yIGZp bmRpbmcgdGhlIGhpZGRlbiBnb3RjaGFzDQpsaWtlIHRoaXMsIHdlIGhhdmUgYSB2ZXJ5IGltcG9y dGFudCBkZXRhaWwgaGVyZSB0aGF0IG1heSBvciBtYXkgbm90IGJlDQpwcm9wZXJseSBjb3ZlcmVk IGluIG91ciBleGlzdGluZyBkb2N1bWVudHMuDQoNCkkgd2VudCBwb2tpbmcgdGhyb3VnaCA2OTA3 LCBhbmQgaXQgY29udGFpbnMgYSB1c2VmdWwgZGVmaW5pdGlvbiBmb3IgYQ0KY292ZXJpbmcgUk9B IHRoYXQgc2VlbXMgdG8gaW1wbHkgdGhhdCBhbiBpbnZhbGlkIFJPQSBjb3VsZCB0ZWNobmljYWxs eQ0Kc3RpbGwgYmUgY29uc2lkZXJlZCBhIGNvdmVyaW5nIFJPQSwgYnV0IGZvciB0aGlzOg0KIkZv ciBhbGwgb2YgdGhlIHVzZSBjYXNlcyBpbiB0aGlzIGRvY3VtZW50LCBpdCBpcyBhc3N1bWVkIHRo YXQgUlBLSQ0KICAgb2JqZWN0cyAoZS5nLiwgcmVzb3VyY2UgY2VydGlmaWNhdGVzLCBST0FzKSB2 YWxpZGF0ZSBpbiBhY2NvcmRhbmNlDQogICB3aXRoIFtSRkM2NDg3XSBhbmQgW1JGQzY0ODBdLiAg SW4gb3RoZXIgd29yZHMsIHdlIGFzc3VtZSB0aGF0DQogICBjb3JydXB0ZWQgUlBLSSBvYmplY3Rz LCBpZiBhbnksIGhhdmUgYmVlbiBkZXRlY3RlZCBhbmQgZWxpbWluYXRlZC4iDQoNClNvIHRoYXQg dGV4dCBleHBsaWNpdGx5IGRlY2xhcmVzIHRoaXMgY2FzZSBvZiBpbnZhbGlkIFJPQSBhbmQgaG93 IHRvDQpoYW5kbGUgaXQgb3V0IG9mIHNjb3BlIGZvciB0aGUgc2NlbmFyaW9zIGRpc2N1c3NlZC4N Cg0KUmVzdGF0aW5nIHRoZSBjb21iaW5hdGlvbiBvZiB0aGlzIHRleHQgYW5kIHlvdXIgYW5zd2Vy IGFib3ZlLCBpcyBpdA0KYWNjdXJhdGUgdG8gc2F5IHRoYXQgaW52YWxpZCBST0FzIGFyZSByZW1v dmVkIGJlZm9yZSB0aGUgUlAgZXZlciBnZXRzIHRvDQp0aGUgc3RlcCB3aGVyZSBpdCBjaGVja3Mg dG8gc2VlIGlmIHRoZXkgYXJlIGNvdmVyaW5nIG9yIG1hdGNoaW5nLCB0aHVzIGl0DQppcyBpbXBv c3NpYmxlIGZvciBhbiBpbnZhbGlkIFJPQSB0byBpbnZhbGlkYXRlIGEgcm91dGU/IElzIHRoYXQg cmVxdWlyZWQNCmJ5IHRoZSBzdGFuZGFyZCwgb3Igc2ltcGx5IGFuIGltcGxlbWVudGF0aW9uIGNv bnZlbnRpb24gdGhhdCBzb21lIG9yIGFsbA0Kb2YgdGhlIGV4aXN0aW5nIFJQIHNvZnR3YXJlIGZv bGxvd3M/DQoNCkkgdGhpbmsgdGhhdCBiZWdzIHNvbWUgZnVydGhlciBxdWVzdGlvbnM6IElzIHRo ZXJlIGV2ZXIgYSBjYXNlIHdoZXJlIHdlDQoqd2FudCogYW4gaW52YWxpZCBST0EgdG8gdHJhbnNs YXRlIHRvIGFuIGludmFsaWQgcm91dGUsIG9yIGRvIHdlICphbHdheXMqDQp3YW50IHRvIHNpbXBs eSBwdW50IHRob3NlIGZyb20gdGhlIHN5c3RlbSBzbyB0aGF0IHRoZSByb3V0ZXMgdGhleSB3b3Vs ZA0KaGF2ZSBjb3ZlcmVkIGFyZSB0ZXN0ZWQgb25seSBhZ2FpbnN0IGFueSByZW1haW5pbmcgdmFs aWQgUk9Bcz8gRG8gd2UgZXZlcg0Kc2VlIGEgbmVlZCB0byB0cmVhdCBhbiBpbnZhbGlkIFJPQSBh cyBhIHJldm9rZT8gSXMgdGhlIGJlaGF2aW9yIGFueQ0KZGlmZmVyZW50IGlmIHRoZSBST0Egd2Fz IHByZXZpb3VzbHkgdmFsaWQgYW5kIHVuZXhwaXJlZCwgYW5kIHN1ZGRlbmx5DQpiZWNvbWVzIGlu dmFsaWQgdnMgaWYgaXQgd2FzIHByZXZpb3VzbHkgdW5rbm93biBhbmQgdGhlIGZpcnN0IFJPQSB0 aGF0DQpzaG93cyB1cCBpcyBpbnZhbGlkPyBJJ20gcXVpdGUgc3VyZSB0aGF0IGRpdmluZyBpbnRv IHRoaXMgd2lsbCBhbHNvDQpnZW5lcmF0ZSBhIGJ1bmNoIG9mIHVucGxlYXNhbnQgcXVlc3Rpb25z IGFib3V0IHRpZWJyZWFrZXIgYmVoYXZpb3Igd2hlbg0KYm90aCB2YWxpZCBhbmQgaW52YWxpZCBS T0FzIG1hdGNoIG9yIGNvdmVyIHByZWZpeGVzLCBzbyBpdCBtYXkgYmUgc2ltcGxlcg0KdG8ganVz dCBtYWtlIGl0IGNsZWFyIHRoYXQgdGhpcyBpcyB0aGUgaW50ZW5kZWQgYmVoYXZpb3IsIGJ1dCBJ IGZpZ3VyZWQNCkknZCBwb3NlIHRoZSBxdWVzdGlvbnMgc2luY2UgdGhhdCdzIHdoYXQgd2Ugc2Vl bSB0byBiZSBoYXZpbmcgYQ0KZnVuZGFtZW50YWwgbWlzdW5kZXJzdGFuZGluZyBhYm91dC4NCg0K SSB0aGluayB0aGF0IHRoZXJlIGFyZSBwcm9iYWJseSBzdGlsbCBjYXNlcyBkdXJpbmcgYSB0cmFu c2ZlciB3aGVyZSBpZiB5b3UNCmdldCB0aGUgb3JkZXIgb2Ygb3BlcmF0aW9ucyB3cm9uZywgaW4g YWRkaXRpb24gdG8gdGhlIGludmFsaWQgUk9BLCB5b3UNCndpbGwgaGF2ZSBhIHNlY29uZCB2YWxp ZCBjb3ZlcmluZyBST0EgdGhhdCBtaWdodCBub3QgbWF0Y2ggd2hhdCdzIGJlaW5nDQphbm5vdW5j ZWQgYW5kIHRodXMgYSBwb3RlbnRpYWxseSBpbnZhbGlkIHJvdXRlLiBUaGF0J3MgcHJvYmFibHkg d2hhdCBuZWVkcw0KdG8gYmUgZW51bWVyYXRlZCBpbiB0aGUgdmFsaWRhdGlvbi1yZWNvbnNpZGVy ZWQgZHJhZnQgYXMgdGhlIHByb2JsZW0gd2l0aA0KdGhlIGJpZ2dlc3QgcG90ZW50aWFsIGltcGFj dCwgZXZlbiBpZiBpdCdzIHNlY29uZGFyeSB0byB0aGUgbWFpbiBmYWlsdXJlDQptb2RlIHdoZXJl IGEgYnVuY2ggb2Ygcm91dGVzIGp1c3QgZ28gdG8gdW5rbm93biBzdGF0dXMgYW5kIHRlbXBvcmFy aWx5DQpsb3NlIHRoZSBwcm90ZWN0aW9uIHRoYXQgb3JpZ2luIHZhbGlkYXRpb24gaXMgc3VwcG9z ZWQgdG8gcHJvdmlkZS4NCg0KVGhhbmtzDQpXZXMgR2VvcmdlDQoNCg0KVGhpcyBFLW1haWwgYW5k IGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJv cHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwg b3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBU aGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZp ZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rp b24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0 byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2lu YWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From nobody Tue Aug 5 10:49:19 2014 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 0294A1B2A9B for ; Tue, 5 Aug 2014 10:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-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 ZRvXEW8h0Do5 for ; Tue, 5 Aug 2014 10:49:11 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11751B2A99 for ; Tue, 5 Aug 2014 10:49:10 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f73so869117yha.24 for ; Tue, 05 Aug 2014 10:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=l645tECwR6c0SohiXGLV4w7BLNZUU8hqA63yo4sEOW4=; b=bU71zP+XKoxepLM8Vxv97zVK995p3dMBFmUOI9tDwa1jAWYwL1V013YVjILlyt28T8 TiIU1xinONMsN/IYqJRRDX4GMXQoVKDL9NjlI11Oev59uWQCQTYRz9jjYzKRs3Eqccb3 z4iPpL6Kzh3K2TzXhUAV7RcMhKPNb/UXmkaJ7ppctbscIemh5pxEK+kB92f5G61IzUPa v9k/RFhgZ8bJgGkoMdhepKUYPkfW7e3fGkVnDIvfZfNhEpuJOU1HXK4xqxuT2upnR6M4 iumsE1ddJYgqrExyC/QVK9t5r/ARy/JNlmWgutV2JjKSe6VioH+rGfjj1W7WZmVTRSPU 5y+w== X-Received: by 10.236.38.71 with SMTP id z47mr8301161yha.18.1407260950166; Tue, 05 Aug 2014 10:49:10 -0700 (PDT) Received: from europa.local ([200.10.62.168]) by mx.google.com with ESMTPSA id b2sm3982839yhi.47.2014.08.05.10.49.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Aug 2014 10:49:09 -0700 (PDT) Message-ID: <53E11912.7050904@gmail.com> Date: Tue, 05 Aug 2014 14:49:06 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> In-Reply-To: <53DAA101.8020305@bbn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/MhA6N5hw71hIbzqKNf4gLpmaiyM Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 17:49:12 -0000 Hello, I think what we need to discuss is which certificate validation rules apply to our problem domain, basically securing origin and/or securing path. Current specs refer that RFC 3779 validation rules should be applied to SIDR's problem domain. I couldn´t find any justification for this, other than 'RFC 3779 was already there by the time SIDR started'. Maybe I'm wrong and this discussion indeed took place. I'd appreciate any pointers. Regarding our draft, maybe we can split the discussion about possible solutions to the problem (as I understand from our last meeting there was rough consensus that there is indeed a problem to be solved here) in two parts: - Unbundling: For example, a wrong ASN list currently invalidates both IPv4 and IPv6 resources in the same cert and down below. It doesn´t seem to make much sense to have a mistake in one resource type invalidate the other two. Discuss #1! - Managing mistakes within the same resource type: Should a mistake in one IPv4 prefix invalidate the whole cert and down below for *all* prefixes? Discuss #2! I agree on keeping the discussion to real world problems and not perceptions. So the 'encouraging sloppiness' argument, whether perhaps having some merit, is not really about a threat or a specific attack or a about a specific problem. cheers! -Carlos From nobody Tue Aug 5 12:12:59 2014 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 69F7E1B2B33 for ; Tue, 5 Aug 2014 12:12:46 -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, RP_MATCHES_RCVD=-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 VaD2X5A1gCvW for ; Tue, 5 Aug 2014 12:12:44 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (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 DA12F1B2B29 for ; Tue, 5 Aug 2014 12:10:58 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XEk8N-0000yt-3U; Tue, 05 Aug 2014 21:10:56 +0200 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-81.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XEk8M-0004SQ-Rt; Tue, 05 Aug 2014 21:10:54 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Tim Bruijnzeels In-Reply-To: Date: Tue, 5 Aug 2014 21:10:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> To: Sandra Murphy X-Mailer: Apple Mail (2.1878.6) X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.6 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.7 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: 784d7acfe6559f2a0b602ec6519a0719721b45da262e97c520db3a69d6c89579 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/DYZdEG17MVJZ3ZGy40sMcAnBRpE Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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: Tue, 05 Aug 2014 19:12:47 -0000 Hi all, On 04 Aug 2014, at 23:47, Sandra Murphy wrote: > speaking as a regular ol' member >=20 > On Aug 4, 2014, at 4:42 PM, "George, Wes" = wrote: >=20 >> Late to the discussion because I needed to have cycles to read and = think >> about this draft... >>=20 >>=20 >> On 7/31/14, 4:03 PM, "Stephen Kent" wrote: >>=20 >=20 >> This is probably true for routes that transition from >> Valid to Unknown, but not if they are actually found to be Invalid, = which >> is what I understand would be the result of the problem discussed in = this >> draft - invalid certs =3D invalid routes.=20 >=20 > Well=85. >=20 > invalid EE certs =3D invalid ROA (for the most part - there's = operational consideration about not removing an EE cert if a repository = is unavailable, I suppose) >=20 > An invalid ROA does not necessarily mean an invalid route. >=20 > If there is no other covering ROA, then a BGP route for that prefix = becomes unknown, as Terry pointed out. >=20 > If there is another ROA which covers the same prefix, then a route may = be invalid -- if no covering ROA authorizes the ASN that the invalidated = ROA mentions. I think we are dealing with a low-risk, but high-impact scenario here. Arguments have been made to depict this as a virtually-no-risk and = low-impact problem, but I am not convinced.=20 I want to reduce the impact because low-risk, low-impact is a much = better place to be.. I believe this is possible without any serious = adverse effects. With regards to impact: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D Origin validation: Indeed: routes would (almost certainly*) go from Valid to Unknown. But, = what are we trying to achieve here by this whole origin validation = thing? Valid is preferred over Unknown, why else would we bother with = this stuff in the first place? Sure, being pushed to Invalid is much = worse, but a complete failure of origin validation for a large part of = the internet (e.g. a whole RIR region) still counts as a high impact = event in my book. *: If a valid ROA exist through another certificate chain then routes = could become Invalid. This scenario is less likely to happen by = accident, because the parent would have to issue the same resource to = more than one child certificate. =3D Path validation: For path validation it was mentioned that there is no =91unknown=92 = state. And I am not sure if it=92s even possible to differentiate here = between =91Invalid=92 vs =91Unknown=92. I expect that the difference = would be: knowing that that a path has been tampered with (key known, = signature invalid) vs not being able to verify (unknown key). This looks = attractive, but I think it opens an easy attack to just sign with a = random key and the path is suddenly =91unknown=92 and not =91invalid=92.. = Maybe I am missing something, if someone has an idea about how this = could work that would be great. Unknown is still a better place to be = than invalid, but only if there is a real difference between the two. So, all in all, I still believe that this *is* a high impact problem. The solution the authors have been suggesting to this problem consists = of *limiting* the impact to just the affected resources. If we had that = we could turn this problem into a low-risk, and much-lower-impact = problem. With regards to risk: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Low risk does not equal no risk. And combined with high impact this is = problematic. While all RIRs and other responsible CAs are using precautions, there = are many moving parts and problems can happen. Bugs in software, human = error, timing issues in publishing parent and child certificates can all = result in inconsistencies between the certificate issued and published = by the parent at a point in time, and what the child believes they have. Currently RIRs maintain their own TAs, and this puts them in a position = where they have full control and knowledge of when changes occur, so = currently the risk these inconsistencies is fairly limited (but not = absent). In case this changes the risk increases. And because it=92s = child certificate that ends up being rejected the immediate impact is on = the party that has the least control over this. Tim From nobody Tue Aug 5 14:11:19 2014 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 21EA31B2BEF for ; Tue, 5 Aug 2014 14:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 qP9pWAkKEX2H for ; Tue, 5 Aug 2014 14:11:10 -0700 (PDT) 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 102D01A02AC for ; Tue, 5 Aug 2014 14:11:10 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:32859 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XEm0w-000MNv-EG for sidr@ietf.org; Tue, 05 Aug 2014 17:11:22 -0400 Message-ID: <53E1486B.1080604@bbn.com> Date: Tue, 05 Aug 2014 17:11:07 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> In-Reply-To: <53E11912.7050904@gmail.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/bfAykWx3OHLLVuycLByNOTb9w4I Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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: Tue, 05 Aug 2014 21:11:16 -0000 Carlos, > Hello, > > I think what we need to discuss is which certificate validation rules > apply to our problem domain, basically securing origin and/or securing path. > > Current specs refer that RFC 3779 validation rules should be applied to > SIDR's problem domain. I couldn´t find any justification for this, other > than 'RFC 3779 was already there by the time SIDR started'. Maybe I'm > wrong and this discussion indeed took place. I'd appreciate any pointers. 3779 was developed for the RPKI context (when S-BGP was the encompassing term); that's why it was adopted by SIDR. The extension was developed by folks with considerable PKI expertise, as a way to make minimal changes to standard PKI path validation., > Regarding our draft, maybe we can split the discussion about possible > solutions to the problem (as I understand from our last meeting there > was rough consensus that there is indeed a problem to be solved here) in > two parts: > > - Unbundling: For example, a wrong ASN list currently invalidates both > IPv4 and IPv6 resources in the same cert and down below. It doesn´t seem > to make much sense to have a mistake in one resource type invalidate the > other two. Discuss #1! The original S-BGP design had 2, essentially parallel PKIs, one for ASNs and one for address blocks. We elected to consolidate the two into one because the CAs are the same in most cases, and it saves space, bandwidth, etc., even though the extensions are distinct. Combining the two trees was seen as a good engineering decision, even though the resources are separate. But, then, so are IPv4 and v6 address prefixes. Do you propose creating separate PKIs for IPv4 and IPv6 addresses? > - Managing mistakes within the same resource type: Should a mistake in > one IPv4 prefix invalidate the whole cert and down below for *all* > prefixes? Discuss #2! Should revocation of a cert with a set of prefixes invalidate all the certs below? (hint, the answer is yes.) The examples cited by you and your fellow authors focus only on errors in 3779 extensions, but why are revocation errors not equally important to address? A PKI based on X.509 yields a binary validity outcome for path validation, plus a set of ancillary info that may be used by an app. One might imagine treating 3779 extensions as ancillary data, but that won't affect the revocation error situation. > I agree on keeping the discussion to real world problems and not > perceptions. So the 'encouraging sloppiness' argument, whether perhaps > having some merit, is not really about a threat or a specific attack or > a about a specific problem. The sloppiness argument is very much a real world issue, based on two decades of experience in the Web PKI environment. Certs used in the Web PKI frequently do not adhere to PKIX specs, validation is sometimes sloppy, and the results have led to real attacks. (For example, a major vendor failed to enforce the CA flag in the Basic Constraints extension, and that allowed attacker to forge certs.) Steve From nobody Tue Aug 5 14:51:09 2014 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 CDB121A008C for ; Tue, 5 Aug 2014 14:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-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 Zm2enf8Eh1bW for ; Tue, 5 Aug 2014 14:51:06 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B601A0073 for ; Tue, 5 Aug 2014 14:51:06 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id 142so1040636ykq.37 for ; Tue, 05 Aug 2014 14:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+tacNRuuF9RRogA+64AvgEMQYEyOVxvdWMrvPqeKJHQ=; b=LQyJyrO9YZB0G+qZEQohrWaxKglRWnwkvdmHwv7E3YPh2hPbslofbXxb5ZAp5l4CvG EVjRervcNuAUHA0YhoGhbKxezrDCFaC8EpO+9mW6gN0UiA2eOfJi9a+A3pWQRnvXcaix jMmpaasF7fL2laLlsGRucZ5o1sUZlXE3YkGvbeD+ORr633U8OwCjGiQxUOLAmKwolLO9 dWfBWZCmQC6OXWsYZaU5qIJMoLaTfxkDiQ9tdOgoALQFQDvNSHzZKkQHVJykgWnj8jIf gfvXtXWhvwpUqWKqf2YZMAL4GAnADLFT6gPwpCxQwy+uKhXiyXnCKoFJ8bd6GnfXuMkB Ge5A== X-Received: by 10.236.85.208 with SMTP id u56mr10225523yhe.48.1407275465759; Tue, 05 Aug 2014 14:51:05 -0700 (PDT) Received: from europa.local ([200.10.62.168]) by mx.google.com with ESMTPSA id v25sm4977047yhi.21.2014.08.05.14.51.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Aug 2014 14:51:04 -0700 (PDT) Message-ID: <53E151C7.1090508@gmail.com> Date: Tue, 05 Aug 2014 18:51:03 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> In-Reply-To: <53E1486B.1080604@bbn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/cRdT6ajjxQEBe694sl0nhLOaCcE Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 21:51:08 -0000 Stephen, (snipping for brevity) On 8/5/14, 6:11 PM, Stephen Kent wrote: > Carlos, > >> Hello, >> >> wrong and this discussion indeed took place. I'd appreciate any pointers. > 3779 was developed for the RPKI context (when S-BGP was the encompassing > term); > that's why it was adopted by SIDR. The extension was developed by folks > with > considerable PKI expertise, as a way to make minimal changes to standard > PKI > path validation., Given that S-BGP failed to gain any traction and most people outside the IETF have never heard of it, I don´t think it sets a particularly encouraging precedent. There is nothing wrong with the extension, nor with the rules per-se. Some of us believe that 3779 rules are not a good match for this particular problem. They may very well be for other, related, problem domains (whole network transfers come to mind now). > But, then, so are IPv4 and v6 address prefixes. Do you propose creating > separate PKIs > for IPv4 and IPv6 addresses? Definitely not. Again, S-BGP is not a particularly good data point. I propose to *unbundle* the analysis of resource types when validating certs. I believe that is clear from my earlier email and from our draft. On the other hand, if you believe that unbundling introduces any new threat, please do comment on that. >> - Managing mistakes within the same resource type: Should a mistake in >> one IPv4 prefix invalidate the whole cert and down below for *all* >> prefixes? Discuss #2! > Should revocation of a cert with a set of prefixes invalidate all > the certs below? (hint, the answer is yes.) The examples cited by > you and your fellow authors focus only on errors in 3779 extensions, > but why are revocation errors not equally important to address? The ability of not being able to correct 1 issue out of 2 doesn´t seem to be a good argument for leaving the 2 unfixed. In addition, revocation errors are way less probable than transient registry inaccuracies. I actually don´t see how we would revoke a cert by mistake, although I´m not saying it cannot happen. If I had to put probabilities to it, I would say 99% of problems will come from registry inaccuracies vs 1% revocation errors. So, if 2 weeks of work (Tim says 1 day, but given he's a particularly gifted coder we´ll give everyone else 14 times as much) can solve 99% (or 90%, or even 80%) of issues and remove a large roadblock for the continuing adoption of OV and RPKI, it seems like a no brainer. The intent of our draft is not to say that RFC 3779 is in error, it just goes to say that the validation model it proposes will possibly create difficult scenarios in real-world RPKI deployments, scenarios that will undermine the trust in the overall solution. regards Carlos From nobody Wed Aug 6 08:45:00 2014 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 8E7B01B2C4A for ; Wed, 6 Aug 2014 08:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 5PIEzVFk-JAD for ; Wed, 6 Aug 2014 08:44:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D68C1B2D16 for ; Wed, 6 Aug 2014 08:44:42 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37031 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XF3OL-0009Ve-8A for sidr@ietf.org; Wed, 06 Aug 2014 11:44:41 -0400 Message-ID: <53E24D68.8020705@bbn.com> Date: Wed, 06 Aug 2014 11:44:40 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> In-Reply-To: <53E151C7.1090508@gmail.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/NwTcLhD72D8O257ptiAgQgoyF5Q Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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, 06 Aug 2014 15:44:49 -0000 Carlos, ... > Given that S-BGP failed to gain any traction and most people outside the > IETF have never heard of it, I don´t think it sets a particularly > encouraging precedent. You asked why 3779. I explained. The were many reasons why S-BGP didn't succeed, but use of 3779 is not likely one of them. > There is nothing wrong with the extension, nor with the rules per-se. > Some of us believe that 3779 rules are not a good match for this > particular problem. They may very well be for other, related, problem > domains (whole network transfers come to mind now). The SIDR WG began meeting in 2006, I believe. The SIDR arch doc was first posted (as an accepted WG I-D) on 2/28/07. It cited 3779 as the basis for the RPKI. It seems curious to me that it has taken 7 years for senior RIR tech staff to determine that there is a problem. You are relatively new to this effort, but what is the excuse for your co-authors? >> But, then, so are IPv4 and v6 address prefixes. Do you propose creating >> separate PKIs >> for IPv4 and IPv6 addresses? > Definitely not. Again, S-BGP is not a particularly good data point. I > propose to *unbundle* the analysis of resource types when validating > certs. I believe that is clear from my earlier email and from our draft. The earlier draft did not contain an algorithm for doing what Geoff has recently suggested as a way to do this. That I-D contained a set of text that tried to convey what the authors wanted to happen, but it was sloppy and focused only on EE cert validation. The current I-D tries to describe a problem space, and it should do so without prejudice wrt a solution. Your comments suggest otherwise. (Also, since you keep criticizing S-BGP, how extensive is your understanding the system, beyond knowing the acronym. Have you read any of the papers, or are your comments based on hearsay?) > ... >> Should revocation of a cert with a set of prefixes invalidate all >> the certs below? (hint, the answer is yes.) The examples cited by >> you and your fellow authors focus only on errors in 3779 extensions, >> but why are revocation errors not equally important to address? > The ability of not being able to correct 1 issue out of 2 doesn´t seem > to be a good argument for leaving the 2 unfixed. Quite the contrary. If a major rationale for changing path validation is to deal with mistakes by RPKI CAs, then let's articulate the rationale clearly and comprehensively, so that it guides our selection of a solution. if we adopt one fix based on an incomplete description of the problem, it may cause us to postpone developing a more comprehensive solution. Also a more comprehensive solution might avoid duplication of mechanisms. > In addition, revocation errors are way less probable than transient > registry inaccuracies. I actually don´t see how we would revoke a cert > by mistake, although I´m not saying it cannot happen. If I had to put > probabilities to it, I would say 99% of problems will come from registry > inaccuracies vs 1% revocation errors. Your numbers seem very speculative to me. At best they are based on the limited experience that RIRs have with managed CA services for clients. So I am not convinced that you have a solid basis for projecting one type of error vs. another when support for CAs run buy net operators is deployed. > So, if 2 weeks of work (Tim says 1 day, but given he's a particularly > gifted coder we´ll give everyone else 14 times as much) can solve 99% > (or 90%, or even 80%) of issues and remove a large roadblock for the > continuing adoption of OV and RPKI, it seems like a no brainer. I agree that there is a "no brainer" here, but you would not like my assessment of why. As Terry noted, the "end of routing as we know it" or taking an entire country offline, claims that were made were misleading, wrt OV. So, why do you see resolution of this issue as a major impediment to continuing adoption of the RPKI? Steve From nobody Fri Aug 8 08:39:11 2014 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 96B011B2B84 for ; Fri, 8 Aug 2014 08:39:10 -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, RP_MATCHES_RCVD=-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 GeBmWNl5TBfd for ; Fri, 8 Aug 2014 08:39:09 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 34E931B2AF2 for ; Fri, 8 Aug 2014 08:39:09 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id E4A8516501E; Fri, 8 Aug 2014 11:39:08 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id 5ED74165012; Fri, 8 Aug 2014 11:39:08 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 8 Aug 2014 11:40:00 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Fri, 8 Aug 2014 11:39:02 -0400 From: Andy Newton To: Stephen Kent Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt Thread-Index: AQHPnD4MWZPJUx8QpU+h2rFbrnAOgJuuUuIAgAFi9wCAADDNAIAAG7gAgAASbgCAAQkngIAARcuAgAAYJwCACYOYgIAHti8AgAA4cYCAAAsogIABK/gAgAMjF4A= Date: Fri, 8 Aug 2014 15:39:01 +0000 Message-ID: <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> In-Reply-To: <53E24D68.8020705@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.87] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0EEDDCE9DFF2634C940621C331ECD37A@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/jsUiV02l_lV6OdNffnkbsjqaOOE Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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: Fri, 08 Aug 2014 15:39:10 -0000 On Aug 6, 2014, at 11:44 AM, Stephen Kent wrote: > Carlos, >=20 > ... >> Given that S-BGP failed to gain any traction and most people outside the >> IETF have never heard of it, I don=B4t think it sets a particularly >> encouraging precedent. > You asked why 3779. I explained. The were many reasons why S-BGP > didn't succeed, but use of 3779 is not likely one of them. >> There is nothing wrong with the extension, nor with the rules per-se. >> Some of us believe that 3779 rules are not a good match for this >> particular problem. They may very well be for other, related, problem >> domains (whole network transfers come to mind now). > The SIDR WG began meeting in 2006, I believe. The SIDR arch doc was first= posted > (as an accepted WG I-D) on 2/28/07. It cited 3779 as the basis for the RP= KI. Either the question Carlos has asked is unanswered or the answer is using c= ircular logic. I cannot tell which. The question was about why, in this effort, we are using 3779 validation ru= les, and the answer appears to be because a past, failed effort used them. = Is there really no technical justification? > It seems curious to me that it has taken 7 years for senior RIR tech staf= f to > determine that there is a problem. You are relatively new to this effort,= but what > is the excuse for your co-authors? C=92mon Steve. You're better than this. -andy From nobody Fri Aug 8 11:04:47 2014 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 645281B2B09 for ; Fri, 8 Aug 2014 11:04:44 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 5Yxy-4A0ACCt for ; Fri, 8 Aug 2014 11:04:42 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C645D1B2B90 for ; Fri, 8 Aug 2014 11:04:41 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id F127528B007B; Fri, 8 Aug 2014 14:04:40 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 71D911F8032; Fri, 8 Aug 2014 14:04:40 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_0C50EE02-4811-4B00-BC5C-DE313D417280"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> Date: Fri, 8 Aug 2014 14:04:39 -0400 Message-Id: <0C1A79F7-5536-4031-A3E1-C0EC582225D7@tislabs.com> References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> To: Andy Newton X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/tcaZaI029snlHHke960mahxTrsg Cc: "sidr@ietf.org" , Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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: Fri, 08 Aug 2014 18:04:45 -0000 --Apple-Mail=_0C50EE02-4811-4B00-BC5C-DE313D417280 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 speaking as regular ol' member On Aug 8, 2014, at 11:39 AM, Andy Newton wrote: >=20 > On Aug 6, 2014, at 11:44 AM, Stephen Kent wrote: >=20 >=20 > The question was about why, in this effort, we are using 3779 = validation rules, and the answer appears to be because a past, failed = effort used them. Is there really no technical justification? > \ and previously On Aug 5, 2014, at 1:49 PM, Carlos M. Martinez = wrote: > Hello, >=20 > I think what we need to discuss is which certificate validation rules > apply to our problem domain, basically securing origin and/or securing = path. >=20 > Current specs refer that RFC 3779 validation rules should be applied = to > SIDR's problem domain. I couldn=B4t find any justification for this, = other > than 'RFC 3779 was already there by the time SIDR started'.=20 The RPKI was intended to certify the rightful holder of a prefix. So it = was designed to follow the current prefix allocation system. In the = current prefix allocation system, you can only allocate prefixes that = you hold. So the RPKI validation rules were designed to ensure that you = can only certify allocations from what you are certified to hold. RFC3779 was also intended to follow the current prefix allocation = system. No surprise, its validation rules ensure that you can only = certify allocations from what you hold. That made RFC3779 useful for = the purposes of providing a RPKI certification of prefix allocation. = Reuse of existing technology that provides the features you want is = generally considered wisdom. This prefix allocation system is encapsulated in the RPSL authorization = model that is used in some RIRs. In those systems, you can only create = an inetnum if you hold the rights to a parent inetnum. That's the authorization model people have been using in some regions = for decades. I have always found the fact that the RPKI authorization = model was a good match to the IRR authorization model in long use to be = reassuring. It meant the RPKI followed what people had already long = accepted, and it meant that operators should find the semantics = familiar. --Sandy, speaking as regular ol' member --Apple-Mail=_0C50EE02-4811-4B00-BC5C-DE313D417280 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT5RE3AAoJEHplpQeet0IZpX0QALsflW9MzDlsvYXPjfFsZZbb mzk24BWaRqBstMNGr53sqeCd+SXhY+8YjwFiRaHmv3j6UiRwy4YJXq22wriNLueo jLj6t/250tyCroprgJM0OBMQPiLfStFJjgl/+zz83yi+YyBp0B5H/rSZs+a2QyqO fViIhmkATiazt0FMUVL1/a9oOgtA4sN1HW7vj8SNkOURbo8qt3FXAfYGIv0ChLAM 1Eci6OHk+tmOzchcscl3XQwr93Fk1jGFxn2US7rGCgvIk0ECAXWR9mPBWBrz5i9D RPjlWt5v03OM8I4izf1/ua+bBRU/566tuQBLkPnUhHdIoXFzUunne92IDf7JJ+KO KKzMQPWu77ldvRpboedsU2AcblzpYAcpP6ik0Dz0XFEKEbVE4L4PqpFG2vviSCQm b1smXAFOim0qvuoAhjfZRqvJPD/a/MXSeBqJlVPHh5esC5chLp7DHqFKEOO+ijrF GAXYeM1Zkh5Lq9D+Xl/y0sJuEMZtg6X5SESkolQ9wkxgS5AOSGQM50B6wf7p1CGL xkAv6cGX2X6MWzAUCuP+t+K0r0ofS+Kg7hOZoDCaBKGh5tAWf3T5WqyXWNj9/8ek PGos0ICzaKXnCQhfP8GwuoWeBYndSSrFd5SuoC3cQxjv5dm8x17lHQBcD15iI2cZ Hm7UhNgAbwJ/51qMxwBs =a86L -----END PGP SIGNATURE----- --Apple-Mail=_0C50EE02-4811-4B00-BC5C-DE313D417280-- From nobody Fri Aug 8 11:36:06 2014 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 6B4FB1A000E for ; Fri, 8 Aug 2014 11:36:04 -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, RP_MATCHES_RCVD=-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 5XgotOqd0TOd for ; Fri, 8 Aug 2014 11:36:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3161A000B for ; Fri, 8 Aug 2014 11:36:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1XFp1E-0008VP-4E; Fri, 08 Aug 2014 18:36:00 +0000 Date: Sat, 09 Aug 2014 03:35:57 +0900 Message-ID: From: Randy Bush To: Andy Newton In-Reply-To: <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/a6AHFVE_AH5KLkGPQKwJJQvHQdY Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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: Fri, 08 Aug 2014 18:36:04 -0000 > The question was about why, in this effort, we are using 3779 > validation rules because we understand how they work formally from considerable experience with PKIs. they are deployed and working today. the wg is considering an other validation process. it is still a bit wobbly, and the need for it is poorly motivated. if you remember, i advocated looking at this as a work item, and came up with the one rather subtle motivation for it. the rest of the motivations seem to involve transfer, which has never been defined or formalized, so can be molded to whatever excuse anybody needs this week. when the rirs are willing to help define transfer, we can look at this from an engineering view, as opposed to emotional and fud. > and the answer appears to be because a past, failed effort used > them. Is there really no technical justification? to paraphrase, C=E2=80=99mon Andy. You're better than this. randy From nobody Fri Aug 8 12:17:56 2014 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 2C9F61A034E for ; Fri, 8 Aug 2014 12:17:55 -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, RP_MATCHES_RCVD=-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 bPY0CaIRubxW for ; Fri, 8 Aug 2014 12:17:53 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 809021A039B for ; Fri, 8 Aug 2014 12:17:47 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 3D605213804; Fri, 8 Aug 2014 15:17:47 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 80B8B213801; Fri, 8 Aug 2014 15:17:46 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 8 Aug 2014 15:18:43 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Fri, 8 Aug 2014 15:17:46 -0400 From: Andy Newton To: Sandra Murphy Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt Thread-Index: AQHPnD4MWZPJUx8QpU+h2rFbrnAOgJuuUuIAgAFi9wCAADDNAIAAG7gAgAASbgCAAQkngIAARcuAgAAYJwCACYOYgIAHti8AgAA4cYCAAAsogIABK/gAgAMjF4CAACivgIAAFG0A Date: Fri, 8 Aug 2014 19:17:45 +0000 Message-ID: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> <0C1A79F7-5536-4031-A3E1-C0EC582225D7@tislabs.com> In-Reply-To: <0C1A79F7-5536-4031-A3E1-C0EC582225D7@tislabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.87] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8E5BDF4475B5C944A9BE39414E233BC6@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Ul34RL81EpBXk73JtDedmI3ylTI Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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: Fri, 08 Aug 2014 19:17:55 -0000 On Aug 8, 2014, at 2:04 PM, Sandra Murphy wrote: > RFC3779 was also intended to follow the current prefix allocation system.= No surprise, its validation rules ensure that you can only certify alloca= tions from what you hold. That made RFC3779 useful for the purposes of pro= viding a RPKI certification of prefix allocation. Reuse of existing techno= logy that provides the features you want is generally considered wisdom. Since we are talking about wisdom, knowing why you are doing something is w= ise. Doing something just because it was done in the past is following trad= ition. > This prefix allocation system is encapsulated in the RPSL authorization m= odel that is used in some RIRs. In those systems, you can only create an i= netnum if you hold the rights to a parent inetnum. >=20 > That's the authorization model people have been using in some regions for= decades. I have always found the fact that the RPKI authorization model = was a good match to the IRR authorization model in long use to be reassurin= g. It meant the RPKI followed what people had already long accepted, and i= t meant that operators should find the semantics familiar. Well, not all IRRs are tied to RIR registrations. In fact, most are not. Reverse DNS might be a better parallel. However, if a particular delegation= is lame, the DNS does not consider all delegations of the network holder t= o be lame. -andy= From nobody Fri Aug 8 12:56:27 2014 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 9DB1E1A03C8 for ; Fri, 8 Aug 2014 12:56:25 -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, RP_MATCHES_RCVD=-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 2Uc2t_5EyRCx for ; Fri, 8 Aug 2014 12:56:24 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 40BDA1A03C4 for ; Fri, 8 Aug 2014 12:56:24 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id F16812136CC; Fri, 8 Aug 2014 15:56:23 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 5AA4F2136B1; Fri, 8 Aug 2014 15:56:23 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 8 Aug 2014 15:57:14 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Fri, 8 Aug 2014 15:56:16 -0400 From: Andy Newton To: Randy Bush Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt Thread-Index: AQHPnD4MWZPJUx8QpU+h2rFbrnAOgJuuUuIAgAFi9wCAADDNAIAAG7gAgAASbgCAAQkngIAARcuAgAAYJwCACYOYgIAHti8AgAA4cYCAAAsogIABK/gAgAMjF4CAADFtgIAAFnKA Date: Fri, 8 Aug 2014 19:56:15 +0000 Message-ID: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.87] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/VnfSfZpDgz0G_Y2Fx5iJQnK-DDc Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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: Fri, 08 Aug 2014 19:56:25 -0000 On Aug 8, 2014, at 2:35 PM, Randy Bush wrote: >> The question was about why, in this effort, we are using 3779 >> validation rules >=20 > because we understand how they work formally from considerable > experience with PKIs. they are deployed and working today. Well ok. Where else are the 3779 rules used? Unfortunately, the RFC index d= oes not list references. > the wg is considering an other validation process. it is still a bit > wobbly, and the need for it is poorly motivated. if you remember, i > advocated looking at this as a work item, and came up with the one > rather subtle motivation for it. I=92m not seeing the relevance of this history lesson to the question that = was asked. How does this relate to the technical reasons of why we are usin= g 3779 rules? > to paraphrase, C=92mon Andy. You're better than this. Imitation is the sincerest form of flattery. I=92m now thinking about shavi= ng off my beard. ;) -andy= From nobody Fri Aug 8 13:14:36 2014 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 20E991B2B49 for ; Fri, 8 Aug 2014 13:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-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 LJgYt_XP6nwE for ; Fri, 8 Aug 2014 13:14:33 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7439B1A0AC7 for ; Fri, 8 Aug 2014 13:14:33 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 142so4176686ykq.24 for ; Fri, 08 Aug 2014 13:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=SaJPbVakZ0BJXJoh9Bnf869oS9YLL/4nSzwzcpxZGwc=; b=XXsWd0w29jS90T79nd8xUA8r1gO1oY5+aCiKuF+28lSrDqaSWJZheEO5iE8+9AqhHw VIq7PBmRSH68kPmU7KGF+Ya/9SU5wx3dEeu9NTxdPulb+aa4lShpKtuhu08SGvcWVZ4+ HBWGHF/NlT98yYwZReZ6ZUh9dt2yds1nnITMFwBPfdcuKv/lp9WOhmyT3PTB0JLIpp0X vPNJkhUZEFDKCTxugo8hmF3XnzwGV9GI1gtYJ7+d3RatQcFQ7bWi/0YMiTH2uLwMiKYH ojaI89b6xJSDWIYlvcGo4U1g/ml8nKvOox8r/DUQG5lb2wlV39tR3ecLg2DQ9fxYkO/O PLgA== X-Received: by 10.236.90.208 with SMTP id e56mr6199110yhf.176.1407528872641; Fri, 08 Aug 2014 13:14:32 -0700 (PDT) Received: from europa.local ([200.10.62.168]) by mx.google.com with ESMTPSA id v43sm7538422yhj.18.2014.08.08.13.14.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 13:14:31 -0700 (PDT) Message-ID: <53E52FA4.7050102@gmail.com> Date: Fri, 08 Aug 2014 17:14:28 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Sandra Murphy , Andy Newton References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> <0C1A79F7-5536-4031-A3E1-C0EC582225D7@tislabs.com> In-Reply-To: <0C1A79F7-5536-4031-A3E1-C0EC582225D7@tislabs.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/yKD6PAwPb9LJnGwb77Deg6-J5A8 Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 20:14:35 -0000 Thanks Sandy, yours is actually the first in this very long and sometimes a bit... strange thread that actually provides an answer to my original question. >From your email I identify a subtly different use case from the one that SIDR seems to be about. #1 - Certify the rightful holder of a prefix #2 - Help routers validate prefixes when deciding how to build their routing tables RFC 3779 validation rules are probably the best suited rules for #1. It seems clear now that whether RFC 3779 validation rules are adequate or well suited to #2 has not been discussed here in depth. It seems to me that this is a good time to do so. Have a great weekend. -Carlos On 8/8/14, 3:04 PM, Sandra Murphy wrote: > speaking as regular ol' member > > On Aug 8, 2014, at 11:39 AM, Andy Newton wrote: > >> >> On Aug 6, 2014, at 11:44 AM, Stephen Kent wrote: >> >> >> The question was about why, in this effort, we are using 3779 validation rules, and the answer appears to be because a past, failed effort used them. Is there really no technical justification? >> \ > > and previously > > On Aug 5, 2014, at 1:49 PM, Carlos M. Martinez wrote: > >> Hello, >> >> I think what we need to discuss is which certificate validation rules >> apply to our problem domain, basically securing origin and/or securing path. >> >> Current specs refer that RFC 3779 validation rules should be applied to >> SIDR's problem domain. I couldn´t find any justification for this, other >> than 'RFC 3779 was already there by the time SIDR started'. > > > The RPKI was intended to certify the rightful holder of a prefix. So it was designed to follow the current prefix allocation system. In the current prefix allocation system, you can only allocate prefixes that you hold. So the RPKI validation rules were designed to ensure that you can only certify allocations from what you are certified to hold. > > RFC3779 was also intended to follow the current prefix allocation system. No surprise, its validation rules ensure that you can only certify allocations from what you hold. That made RFC3779 useful for the purposes of providing a RPKI certification of prefix allocation. Reuse of existing technology that provides the features you want is generally considered wisdom. > > This prefix allocation system is encapsulated in the RPSL authorization model that is used in some RIRs. In those systems, you can only create an inetnum if you hold the rights to a parent inetnum. > > That's the authorization model people have been using in some regions for decades. I have always found the fact that the RPKI authorization model was a good match to the IRR authorization model in long use to be reassuring. It meant the RPKI followed what people had already long accepted, and it meant that operators should find the semantics familiar. > > > --Sandy, speaking as regular ol' member > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Fri Aug 8 13:24:15 2014 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 A3AE81A854D for ; Fri, 8 Aug 2014 13:24:10 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 bMlCJ5b5JG2i for ; Fri, 8 Aug 2014 13:24:08 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864B21A0316 for ; Fri, 8 Aug 2014 13:24:08 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id C144228B0040; Fri, 8 Aug 2014 16:24:07 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 5D6B51F8032; Fri, 8 Aug 2014 16:23:18 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6DC6FF9B-7132-42B1-94B6-D3E06F277573"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Fri, 8 Aug 2014 16:23:12 -0400 Message-Id: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> <0C1A79F7-5536-4031-A3E1-C0EC582225D7@tislabs.com> To: Andy Newton X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/GRFcW_jVw6pKI1H3QJQE6BgEAaM Cc: "sidr@ietf.org" , Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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: Fri, 08 Aug 2014 20:24:10 -0000 --Apple-Mail=_6DC6FF9B-7132-42B1-94B6-D3E06F277573 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 8, 2014, at 3:17 PM, Andy Newton wrote: >=20 > On Aug 8, 2014, at 2:04 PM, Sandra Murphy wrote: >=20 >> RFC3779 was also intended to follow the current prefix allocation = system. No surprise, its validation rules ensure that you can only = certify allocations from what you hold. That made RFC3779 useful for = the purposes of providing a RPKI certification of prefix allocation. = Reuse of existing technology that provides the features you want is = generally considered wisdom. >=20 > Since we are talking about wisdom, knowing why you are doing something = is wise. Doing something just because it was done in the past is = following tradition. You mischaracterize the motivation. I indicated that the desired = features of the RPKI design matched the features provided by an existing = technology. That is decidedly not just following tradition. For example, the RPKI also uses CMS, because it provides the features = the RPKI needs. That is not just following tradition. >=20 >> This prefix allocation system is encapsulated in the RPSL = authorization model that is used in some RIRs. In those systems, you = can only create an inetnum if you hold the rights to a parent inetnum. >>=20 >> That's the authorization model people have been using in some regions = for decades. I have always found the fact that the RPKI authorization = model was a good match to the IRR authorization model in long use to be = reassuring. It meant the RPKI followed what people had already long = accepted, and it meant that operators should find the semantics = familiar. >=20 > Well, not all IRRs are tied to RIR registrations. In fact, most are = not. I mentioned those used in some RIRs. I did not address all IRRs. Yes, most do not. Those that do not are subject to unauthorized = registrations. As has happened. =20 I am not sure why you are bringing up systems which provide no security = in discussing the design of a secure system. As an example of what to = avoid? >=20 > Reverse DNS might be a better parallel. However, if a particular = delegation is lame, the DNS does not consider all delegations of the = network holder to be lame. >=20 I do not follow the parallel at all. --Sandy --Apple-Mail=_6DC6FF9B-7132-42B1-94B6-D3E06F277573 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT5TGwAAoJEHplpQeet0IZthgP+gIRe9aUs1+pq3pbhyNnW2IA jyEs5rsFM0tDmhMWJtDkYf6nc3hk+9PAgaAEz7dzi6/lmpmwxlHwo133uNbRVF7+ +pted22wD6Od6BeE7AgOdLPMwOYp3xD3VLYuKOb/6Nd6KGMH5iF9oQ0ydg64OEgJ lQAi4iJjbyJgfUDglhgtHJsLY64Bx82s3icfMQvjv5iznwbjCJ5aIA+Tx0oxRG2+ hkTZoAAHfFRy2jRpQBJik8GiiUzGRtEuEAaKtQocBte9gNL0If0XmNObr1OIecFs vyi/demQ5wdzA4dj6XQFSV/9wgvUjHsfhYIU5PGascWY5q6q+HmJQOECGF5uiauB zA1BgQ5cgPaNrAmFwVMz+iYZCw4FVXnO7OWJidH/lZ1fxagI+Yd3583JwamtRvTG 7Bedd/HtlRKzrEGm7Dfk7KX5IwzyrIhmKjRkIrRvu8strGIj22rPq7iJKRLjiCqB 0PukNGjIlg0GEG7OWWX0GYlgLDa9PMxKm5P3Mp1mMUsXIyZIMZs4kngCvF7ytYdD MGQ6ky5VwLHg51C64Bw8Ii1BfPZVz7FzfsEOU5sDNhqohpAkeG752GbdzPwtSV5c TCZoyxpRdFTJQ01h4HuPVm88RE2xnDLmeqC+t5Im7SPPG+MIhutMahmBR7RwHRde +4a8WIoMxICgZs27w5/W =Vad/ -----END PGP SIGNATURE----- --Apple-Mail=_6DC6FF9B-7132-42B1-94B6-D3E06F277573-- From nobody Fri Aug 8 13:25:40 2014 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 C7FA21A011E for ; Fri, 8 Aug 2014 13:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-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 DPfpzOUltfHJ for ; Fri, 8 Aug 2014 13:25:35 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811B01A0109 for ; Fri, 8 Aug 2014 13:25:35 -0700 (PDT) Received: by mail-yk0-f181.google.com with SMTP id q200so4223785ykb.40 for ; Fri, 08 Aug 2014 13:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=GBZQGDzJKqiRua2Un+MKRsidDjmhXV/s9lQDqooxi9g=; b=W4AwkUudiau9uYry59habF+BJWzvZKYG5npiPngmGFrC8wMO5PUtCCZb9i22FufNuP 1TDhLMmcKk01QPQ4WDGauzB0LTZGiskX7sfrCqMtyirAIkIDV64vU3dtopcvKzjHeInz r+m6b7CEi+iFuWi97dJ1p/8DZvANmukjM1rexnavfSBj2LpC95xtAf9PGKrw1oET9wAz 9KaJfUmpHQp/vPlViDCbO9PZZmNhSqDuIaCUvuySLfNJGsLDj+y97dOczsMkdmCAODdZ SyHOmuIRkETYb+p9Jt0RKzOTsLV0sNlifI51PwklcXy5s0F1M9eGuA4nTeAmPG1fsDCb 04sA== X-Received: by 10.236.116.202 with SMTP id g50mr7355951yhh.147.1407529534886; Fri, 08 Aug 2014 13:25:34 -0700 (PDT) Received: from europa.local ([200.10.62.168]) by mx.google.com with ESMTPSA id k38sm7593629yhg.13.2014.08.08.13.25.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 13:25:33 -0700 (PDT) Message-ID: <53E5323B.8010908@gmail.com> Date: Fri, 08 Aug 2014 17:25:31 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Stephen Kent , sidr@ietf.org References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> In-Reply-To: <53E24D68.8020705@bbn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/JaDNck_trEsW3EkWMNB_ia9wlI8 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 20:25:37 -0000 Hi Steve, On 8/6/14, 12:44 PM, Stephen Kent wrote: > Carlos, > > ... > It seems curious to me that it has taken 7 years for senior RIR tech > staff to > determine that there is a problem. You are relatively new to this > effort, but what > is the excuse for your co-authors? I like reading here that there indeed you acknowledge that indeed *there is* a problem. We have some progress then. Sorry for being slow though, I promise to be better in the future. >>> But, then, so are IPv4 and v6 address prefixes. Do you propose creating >>> separate PKIs >>> for IPv4 and IPv6 addresses? >> Definitely not. Again, S-BGP is not a particularly good data point. I >> propose to *unbundle* the analysis of resource types when validating >> certs. I believe that is clear from my earlier email and from our draft. > The earlier draft did not contain an algorithm for doing what > Geoff has recently suggested as a way to do this. That I-D contained > a set of text that tried to convey what the authors wanted to happen, > but it was sloppy and focused only on EE cert validation. The current > I-D tries to describe a problem space, and it should do so without > prejudice wrt a solution. Your comments suggest otherwise. > (Also, since you keep criticizing S-BGP, how extensive is your > understanding Steve, you put words in my mouth, words that I didn't say. I don't criticize s-BGP. For all I know, it may very well be the best technology ever designed. However, the fact that it failed to gain any traction is undeniable. You might argue that the world at large is stupid and they failed to acknowledge they had the cure for everything in S-BGP, but I think we all know better than that. > the system, beyond knowing the acronym. Have you read any of the papers, > or are > your comments based on hearsay?) Mmmm I tried to find a single operator running S-BGP and failed. Sorry. Steve, I think you're taking this too personally. I understand that 3779 is your brainchild, and no one is saying that it is 'wrong' in any sense. The question about whether it is applicable to route and path validation as it is is a valid one, and there is very, very little coming from the rest of the WG explaining why we need strict 3779 or detailing what new attack vectors would be introduced by validation-revisited. Have a great weekend. -Carlos From nobody Fri Aug 8 14:17:07 2014 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 C18D41A00D7 for ; Fri, 8 Aug 2014 14:17:00 -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, RP_MATCHES_RCVD=-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 rw9wJWWCEnZL for ; Fri, 8 Aug 2014 14:16:53 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 831481A0345 for ; Fri, 8 Aug 2014 14:16:53 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 3EBB1213801; Fri, 8 Aug 2014 17:16:53 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 6B33C2137ED; Fri, 8 Aug 2014 17:16:52 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 8 Aug 2014 17:17:32 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Fri, 8 Aug 2014 17:16:51 -0400 From: Andy Newton To: Sandra Murphy Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt Thread-Index: AQHPnD4MWZPJUx8QpU+h2rFbrnAOgJuuUuIAgAFi9wCAADDNAIAAG7gAgAASbgCAAQkngIAARcuAgAAYJwCACYOYgIAHti8AgAA4cYCAAAsogIABK/gAgAMjF4CAACivgIAAFG0AgAASSACAAA7/AA== Date: Fri, 8 Aug 2014 21:16:50 +0000 Message-ID: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> <0C1A79F7-5536-4031-A3E1-C0EC582225D7@tislabs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.87] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/N2D5Edq7wDuta2-5NDDn2yROOys Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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: Fri, 08 Aug 2014 21:17:01 -0000 On Aug 8, 2014, at 4:23 PM, Sandra Murphy wrote: >=20 > On Aug 8, 2014, at 3:17 PM, Andy Newton wrote: >=20 >>=20 >> On Aug 8, 2014, at 2:04 PM, Sandra Murphy wrote: >>=20 >>> RFC3779 was also intended to follow the current prefix allocation syste= m. No surprise, its validation rules ensure that you can only certify allo= cations from what you hold. That made RFC3779 useful for the purposes of p= roviding a RPKI certification of prefix allocation. Reuse of existing tech= nology that provides the features you want is generally considered wisdom. >>=20 >> Since we are talking about wisdom, knowing why you are doing something i= s wise. Doing something just because it was done in the past is following t= radition. >=20 > You mischaracterize the motivation. I indicated that the desired feature= s of the RPKI design matched the features provided by an existing technolog= y. That is decidedly not just following tradition. I=92m fine with not characterizing motives and historical context. Just fol= lowing your lead. :) > For example, the RPKI also uses CMS, because it provides the features the= RPKI needs. That is not just following tradition. CMS is used in many deployed systems. As has been asked but has been left u= nanswered, in what other deployed systems is 3779 used? The grounds for cha= nging the 3779 rules has been described as =93wobbly=94 but how is that acc= usation made if we cannot put our fingers on the reasons for the 3779 rules= in the first place? >>> This prefix allocation system is encapsulated in the RPSL authorization= model that is used in some RIRs. In those systems, you can only create an= inetnum if you hold the rights to a parent inetnum. >>>=20 >>> That's the authorization model people have been using in some regions f= or decades. I have always found the fact that the RPKI authorization mode= l was a good match to the IRR authorization model in long use to be reassur= ing. It meant the RPKI followed what people had already long accepted, and= it meant that operators should find the semantics familiar. >>=20 >> Well, not all IRRs are tied to RIR registrations. In fact, most are not. >=20 > I mentioned those used in some RIRs. I did not address all IRRs. >=20 > Yes, most do not. Those that do not are subject to unauthorized registra= tions. As has happened. =20 >=20 > I am not sure why you are bringing up systems which provide no security i= n discussing the design of a secure system. As an example of what to avoid= ? Again, I was following your lead by addressing the example you gave. >>=20 >> Reverse DNS might be a better parallel. However, if a particular delegat= ion is lame, the DNS does not consider all delegations of the network holde= r to be lame. >>=20 >=20 > I do not follow the parallel at all. If you are looking for a system that follows the address allocation hierarc= hy, reverse DNS is one such system. However, I get the feeling you and I ar= e talking past each other. If that was not the characteristic you were desc= ribing or I have done a poor job explaining my point, please let me know. -andy From nobody Fri Aug 8 15:17:47 2014 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 518CE1A0127 for ; Fri, 8 Aug 2014 15:17:46 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 K80AYIuk5_pm for ; Fri, 8 Aug 2014 15:17:41 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 133DD1A0126 for ; Fri, 8 Aug 2014 15:17:41 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 65ACE28B0053; Fri, 8 Aug 2014 18:17:40 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 332C71F8032; Fri, 8 Aug 2014 18:17:39 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_62B2901A-EB6E-4737-93F8-D539B286D735"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Fri, 8 Aug 2014 18:17:39 -0400 Message-Id: <072C1DD2-658A-42A1-B44C-627387C27842@tislabs.com> References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> <0C1A79F7-5536-4031-A3E1-C0EC582225D7@tislabs.com> To: Andy Newton X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/9Arhv--L4lRWgcpILMQWQ-tSSS8 Cc: "sidr@ietf.org" , Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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: Fri, 08 Aug 2014 22:17:46 -0000 --Apple-Mail=_62B2901A-EB6E-4737-93F8-D539B286D735 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 speaking as regular ol' member On Aug 8, 2014, at 5:16 PM, Andy Newton wrote: >=20 > On Aug 8, 2014, at 4:23 PM, Sandra Murphy wrote: >=20 >>=20 >> On Aug 8, 2014, at 3:17 PM, Andy Newton wrote: >>=20 >>>=20 >>> On Aug 8, 2014, at 2:04 PM, Sandra Murphy wrote: >>>=20 >>=20 >> You mischaracterize the motivation. I indicated that the desired = features of the RPKI design matched the features provided by an existing = technology. That is decidedly not just following tradition. >=20 > I=92m fine with not characterizing motives and historical context. = Just following your lead. :) I did not mention motives, I mentioned motivations, as in the = requirements that drove the design. I did not suggest 3779 was adopted because it existed but because it had = the desirable features. So you may think you are following my lead, but I think you are not on = the same path I'm on. >=20 >> For example, the RPKI also uses CMS, because it provides the features = the RPKI needs. That is not just following tradition. >=20 > CMS is used in many deployed systems. As has been asked but has been = left unanswered, in what other deployed systems is 3779 used? The = grounds for changing the 3779 rules has been described as =93wobbly=94 = but how is that accusation made if we cannot put our fingers on the = reasons for the 3779 rules in the first place? I think I answered that. The RPKI was designed for the prefix allocation = system. In the prefix allocation system, one can allocate only from the = allocation one holds. 3779 also was designed to follow the prefix = allocation system and its rules enforce that allocation behavior. It = provided the features a certification of the prefix allocation system = needed, so it was adopted. I suppose we could have invented an entirely new crypto based system, = but the prefix allocation system's behavior would have been part of what = we built anyway. 3779 did not invent the encompassing rules, those rules = are derived from the behavior of the existing system. >=20 >>>> This prefix allocation system is encapsulated in the RPSL = authorization model that is used in some RIRs. In those systems, you = can only create an inetnum if you hold the rights to a parent inetnum. >>>>=20 >>>> That's the authorization model people have been using in some = regions for decades. I have always found the fact that the RPKI = authorization model was a good match to the IRR authorization model in = long use to be reassuring. It meant the RPKI followed what people had = already long accepted, and it meant that operators should find the = semantics familiar. >>>=20 >>> Well, not all IRRs are tied to RIR registrations. In fact, most are = not. >>=20 >> I mentioned those used in some RIRs. I did not address all IRRs. >>=20 >> Yes, most do not. Those that do not are subject to unauthorized = registrations. As has happened. =20 >>=20 >> I am not sure why you are bringing up systems which provide no = security in discussing the design of a secure system. As an example of = what to avoid? >=20 > Again, I was following your lead by addressing the example you gave. I was talking about IRR/RPSL systems that follow the authorization = model. You pointed out examples of those that do not. That's not = following my lead. I was attempting to point out that the only other existing system with = an authorization model also follows the same encompassing rule. Again, = the encompassing rule is derived from the behavior of the prefix = allocation system. >=20 >>>=20 >>> Reverse DNS might be a better parallel. However, if a particular = delegation is lame, the DNS does not consider all delegations of the = network holder to be lame. >>>=20 >>=20 >> I do not follow the parallel at all. >=20 > If you are looking for a system that follows the address allocation = hierarchy, reverse DNS is one such system. However, I get the feeling = you and I are talking past each other. If that was not the = characteristic you were describing or I have done a poor job explaining = my point, please let me know. The parallel to DNS delegation that is bad would be one RPKI certificate = that is bad. The parallel to "all delegations of the network holder" would be "all = RPKI certificates of a resource holder". So the parallel is: if a particular RPKI certificate is bad, the system = does not consider all RPKI certificates of the resource holder to be = bad. True. So I don't follow why you think this parallel is better. But I'm not = sure that it helps the discussion to explore it. If you think it would, = maybe we better take it off list? --Sandy, speaking as regular ol' member --Apple-Mail=_62B2901A-EB6E-4737-93F8-D539B286D735 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT5UyDAAoJEHplpQeet0IZTWkQAJqiKVnGi4YM3EJFF4GJI+Xu 0L42Xcw887IuMsZwfr9NXsH1tlMXTL8Ib8RKSVlm+hHrTtpTzDw3FiGiYryPDMcD r+q7jt6K/Lr0oEwjx2DrFTrOFrFwxFuKpcFOzwsJ1dR3hN8OCVcRXmN5HKs+D1El r4he2QtkKq9GqfkRMb2WN1gOPLCPrv7Vvwv3hg+7KoE/tGjJSAGyHupT09vpzil1 HZSH+bVfKkZWqODARDJP2Lz6x6rtfteT/sMi4T+w8P306v/ZIk0QYsFS0PjO9vfV fh4ZVdrgWi1SXbanaAqvNm0bjAHGxp0h99Z/bEaNdzu54TmxWuku7Gv+WPtMj37Z qg2NtGycfPbKJKciyFk+GC0hI4+pxQuuEjC7TjlV5kY3KPp45c+bko1iaaLq9RlY llYHPBCwDO+odsjQeeSGqpk65sMjKozpiD6T7QDiDm+SEw4BErBNGNv9OfDtakfW NfHf02sKjm5sKvZcBuLiI0GHWhYszkCMA6/3Uiu3fegIZkn+WbAU864+Q0/dpIqJ 9ghzsWnnJAnbGBgNNiBngZTUHEwV9W8/5Ws5Ye+tcIMwbnrDD26D2oOy3u3TvQVc 4Ma7bXRDmPBG9floUAhpIrMt2gId+KotUt4Lxi8MutLv9O/bu4Vg2ywZRiM3Y/bF Is40rUV89Fc3Nb5N3WmR =Zbhm -----END PGP SIGNATURE----- --Apple-Mail=_62B2901A-EB6E-4737-93F8-D539B286D735-- From nobody Fri Aug 8 18:56:05 2014 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 AF5BC1A0444 for ; Fri, 8 Aug 2014 18:56:02 -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, RP_MATCHES_RCVD=-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 mDb-jDTZIV-G for ; Fri, 8 Aug 2014 18:56:01 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66C151A0416 for ; Fri, 8 Aug 2014 18:56:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1XFvt0-0000oz-D1; Sat, 09 Aug 2014 01:55:58 +0000 Date: Sat, 09 Aug 2014 10:55:56 +0900 Message-ID: From: Randy Bush To: "Carlos M. Martinez" In-Reply-To: <53E52FA4.7050102@gmail.com> References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> <0C1A79F7-5536-4031-A3E1-C0EC582225D7@tislabs.com> <53E52FA4.7050102@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/0Dlx3ZQaUX9BhTahtzCo3n3fwdc Cc: "sidr@ietf.org" , Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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: Sat, 09 Aug 2014 01:56:02 -0000 > #1 - Certify the rightful holder of a prefix > #2 - Help routers validate prefixes when deciding how to build their > routing tables > > RFC 3779 validation rules are probably the best suited rules for #1. It > seems clear now that whether RFC 3779 validation rules are adequate or > well suited to #2 has not been discussed here in depth. i think you are a bit confused here. what geoff proposed changes nothing about 1 and 2. it's about how one validates the correctness of the external data, irrespective of how it is used. randy From nobody Fri Aug 8 19:42:33 2014 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 398451A0359 for ; Fri, 8 Aug 2014 19:42:31 -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, RP_MATCHES_RCVD=-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 IL7dUjYGzWJ2 for ; Fri, 8 Aug 2014 19:42:29 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA751A0351 for ; Fri, 8 Aug 2014 19:42:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1XFwbx-000164-MO; Sat, 09 Aug 2014 02:42:26 +0000 Date: Sat, 09 Aug 2014 11:42:23 +0900 Message-ID: From: Randy Bush To: Andy Newton In-Reply-To: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/yPldWEKSmVqf9VdF9E2QOTr8iSY Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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: Sat, 09 Aug 2014 02:42:31 -0000 >>> The question was about why, in this effort, we are using 3779 >>> validation rules >> because we understand how they work formally from considerable >> experience with PKIs. they are deployed and working today. > Well ok. Where else are the 3779 rules used? the validation for 3779 is essentially the same as for X.509, a rigid hierarchy. some do not like different aspects of that rigidity, i am among them, but for different aspects than this one. >> the wg is considering an other validation process. it is still a bit >> wobbly, and the need for it is poorly motivated. if you remember, i >> advocated looking at this as a work item, and came up with the one >> rather subtle motivation for it. > I=E2=80=99m not seeing the relevance of this history lesson to the questi= on > that was asked. How does this relate to the technical reasons of why > we are using 3779 rules? because they are working. you are proposing a change to a deployed rfc. what is the motivation for the change? be technically explicit. the point of the history lesson of the rirs blocking the definition and documentation of transfer is that it seems to be the only serious reason for the change those very same rirs are proposing. so, if you want your proposal to change rfced running code to be taken seriously, you had best document it technically, not just throw perjoratives and hyperbole. once again, i was the first (non author) to advocate the wg working on this, and did put up one very subtle possible motivation. unlike the rir mafia, i am not threatening to hold my breath until i am blue if it gets consensus (or not); my youngest grandchild has grown past that phase. i just want clear and well-understood technical reasons for a change to deployed running documented code that seems to be working. >> to paraphrase, C=E2=80=99mon Andy. You're better than this. > Imitation is the sincerest form of flattery. I=E2=80=99m now thinking abo= ut > shaving off my beard. ;) not likely. the last time i was beardless jack kennedy was president. i do not change running beard without a sound technical reason. otoh, if you can document how i can transfer to a 27 year old body, we would likely have a deal. randy From nobody Mon Aug 11 04:10:36 2014 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 23E3E1A03FF for ; Mon, 11 Aug 2014 04:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-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 v0lgDb7XXQpM for ; Mon, 11 Aug 2014 04:10:32 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 634C91A03F9 for ; Mon, 11 Aug 2014 04:10:32 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id f10so6078058yha.34 for ; Mon, 11 Aug 2014 04:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YMZXG/MOxXMPFKk5XuxOxPxrqdtLWG4GjT4JtKheTPI=; b=cP1B6/KyuWeDmACIkWz/flACG6TGUKYAdiyeHAsCibOSdllYpJtYt6miRsWG2VWcXz /OZxO8bbfPZ0qTGhUApubwmnvZf9Y7GNI3HO99Ym7urzq8AlM0qRQyxfnMPIH/jBDzZH HQh8Nh57V2h0Lh8TxiuqGDroFdz++1R0YhS/OCSTdlQbUT1v5TqWgnlFA8UPlVCRu0l5 YU0+3xdtSuwTtosOiQo7P56bJPKJOnRplZftKJGeD2uyrFW5XzQgZKSp3O3K4OEADvqy f7dQM0hMVrtyAF9Kdorwdj4evDmJZWQbDghFlsdaKkkUptPsbkOJbo6GFPwtHAPdy+Mp rAmA== X-Received: by 10.236.223.36 with SMTP id u34mr41390327yhp.79.1407755431629; Mon, 11 Aug 2014 04:10:31 -0700 (PDT) Received: from houston.local ([207.239.162.230]) by mx.google.com with ESMTPSA id w3sm23058394yhk.6.2014.08.11.04.10.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Aug 2014 04:10:30 -0700 (PDT) Message-ID: <53E8A4A5.6000809@gmail.com> Date: Mon, 11 Aug 2014 08:10:29 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Randy Bush , Andy Newton References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/37KbiyzgrSCl_qoP6C1NIUaztWs Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 11:10:33 -0000 Hi, On 8/8/14, 3:35 PM, Randy Bush wrote: >> The question was about why, in this effort, we are using 3779 >> validation rules > > because we understand how they work formally from considerable > experience with PKIs. they are deployed and working today. > Where? Can you provide examples? I seem to be having a really hard time finding real, widespread world uses of RFC 3779, outside RPKI that is. As a another data point, most people attending LACNIC conferences had never heard of RFC 3779 validation before Arturo and myself brought RPKI into their radars. And among those you can count engineering depts of ISPs counting their user base in tens of millions. regards -Carlos From nobody Mon Aug 11 04:13:48 2014 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 9E6B01A0407 for ; Mon, 11 Aug 2014 04:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-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 JoYWQf1GVs_R for ; Mon, 11 Aug 2014 04:13:45 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15C71A03FF for ; Mon, 11 Aug 2014 04:13:44 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id c41so6091568yho.40 for ; Mon, 11 Aug 2014 04:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jHoprIg/HHfi7h5D62z/UxL53kLf3h34qKwfYf5GoWk=; b=dPkJV6ynaIei0xlgE1YF7YnJg6h1pSrXLGdm0YPZeAbkAPAfXtCMXeozk3v7czNkKA TnXmOh99539Ec8WWWR4xpZpNQlFJCZm9FVh/rO2BjAlKX78OPooQLWU0o89XUewKB0b0 FBHTn5j2HZzQTuJzvh56ZHtXFAuh/E15q6Iu4AD1z9AnTDQTQBwLtJeY6Hq4OUNGV6ZY 5E9xQV08Hn2aycMkOXYo6jICuZCI8GLat/y2XXRjqPmihxbbsws8ITm7AIiBGnnY5Dm+ koqs1gF3LlgXUeEt+0cheK8or2wcUUPAKxoOnSlmu/8wBXv9RplD2PrRPQEsqoROmIN+ x9Mg== X-Received: by 10.236.202.175 with SMTP id d35mr502229yho.192.1407755624108; Mon, 11 Aug 2014 04:13:44 -0700 (PDT) Received: from houston.local ([207.239.162.230]) by mx.google.com with ESMTPSA id l46sm23042231yhq.44.2014.08.11.04.13.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Aug 2014 04:13:43 -0700 (PDT) Message-ID: <53E8A565.3010402@gmail.com> Date: Mon, 11 Aug 2014 08:13:41 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Randy Bush References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> <0C1A79F7-5536-4031-A3E1-C0EC582225D7@tislabs.com> <53E52FA4.7050102@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/2T1qg2wBYCPV1e9bOcsLXyoUHyI Cc: "sidr@ietf.org" , Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 11:13:45 -0000 I'm not defending the draft per se here. Maybe I should start a new thread. I think we, as SIDR, need to revisit some basics and some 'axioms' that have been taken for granted, in particular, why are we using RFC 3779 rules here. So far we got: 1- because they were used in s-BGP 2- because they ware already there 3- because we understand them So far, this looks quite 'wobbly' too. This actually doesn't mean that the proposal of the draft is the 'right' one, but I think we need to re-discuss this before the RPKI gets more traction and people get burn scars. Wes's email is pretty clear, risk vs reward. cheers! -Carlos On 8/8/14, 10:55 PM, Randy Bush wrote: >> #1 - Certify the rightful holder of a prefix >> #2 - Help routers validate prefixes when deciding how to build their >> routing tables >> >> RFC 3779 validation rules are probably the best suited rules for #1. It >> seems clear now that whether RFC 3779 validation rules are adequate or >> well suited to #2 has not been discussed here in depth. > > i think you are a bit confused here. > > what geoff proposed changes nothing about 1 and 2. it's about how one > validates the correctness of the external data, irrespective of how it > is used. > > randy > From nobody Mon Aug 11 05:58:29 2014 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 71F141A07AA for ; Mon, 11 Aug 2014 05:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.466 X-Spam-Level: * X-Spam-Status: No, score=1.466 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.668, SPF_PASS=-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 OdTLmj0Roj4B for ; Mon, 11 Aug 2014 05:58:26 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9F69B1A0759 for ; Mon, 11 Aug 2014 05:58:26 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.01,841,1400040000"; d="scan'208";a="441003645" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 11 Aug 2014 08:57:39 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 11 Aug 2014 08:58:25 -0400 From: "George, Wes" To: "carlos@lacnic.net" , "Carlos M. Martinez" , Randy Bush Date: Mon, 11 Aug 2014 08:58:24 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt Thread-Index: Ac+1Y/CAocDXGfIpTNmh6GRzZwfrgw== Message-ID: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> <0C1A79F7-5536-4031-A3E1-C0EC582225D7@tislabs.com> <53E52FA4.7050102@gmail.com> <53E8A565.3010402@gmail.com> In-Reply-To: <53E8A565.3010402@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/NkM5r-3PmLYPA6aamDMP5GlneSc Cc: Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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, 11 Aug 2014 12:58:27 -0000 DQpPbiA4LzExLzE0LCA3OjEzIEFNLCAiQ2FybG9zIE0uIE1hcnRpbmV6IiA8Y2FybG9zbTMwMTFA Z21haWwuY29tPiB3cm90ZToNCg0KPjMtIGJlY2F1c2Ugd2UgdW5kZXJzdGFuZCB0aGVtDQoNCkZv ciBzbWFsbCB2YWx1ZXMgb2YgIndlIiBhbmQgInVuZGVyc3RhbmQiDQoNCjstKQ0KDQpXZXMNCg0K DQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1l IFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdl ZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGlt ZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3Ug YXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24s IGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2Yg YW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5k IG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkg ZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBw cmludG91dC4NCg== From nobody Mon Aug 11 06:02:03 2014 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 EF10F1A03C5 for ; Mon, 11 Aug 2014 06:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.269 X-Spam-Level: X-Spam-Status: No, score=-13.269 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 EYZPetX1eLr3 for ; Mon, 11 Aug 2014 06:01:57 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7906F1A0176 for ; Mon, 11 Aug 2014 06:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15571; q=dns/txt; s=iport; t=1407762117; x=1408971717; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sdBH6mahdSY0c71354lP82/xHMhcbW40B30nBp20Pgg=; b=PbLqSLHarCamRrMvZM2w4q4tig7ga45bjWgUtlM8f8TFP5mWcaI//Kmm ns2Z1lMuSFnUsd3NCMke1eVr4+b6yU+KygQzsKko+BNpHJRWk/ZU/N7AW +TuEEM3cURrMZwL+aXnQTFdRYmbsLKxmQLZqZXqn1FyshdZ2Zbn+afEVO A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAOW96FOtJA2M/2dsb2JhbABbgw1SVwTMegEJh0gBgRcWd4QEAQEEAQEBaAMEBxACAQg/BycLFBECBAoEBRuIJw3BPBePA0kHgy+BHQWPBoIThCWCOYQ4gVeTJINcbAEBgQMBAR4CAgIc X-IronPort-AV: E=Sophos;i="5.01,841,1400025600"; d="scan'208,217";a="346395986" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP; 11 Aug 2014 13:01:56 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s7BD1u7Q002340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Aug 2014 13:01:56 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.73]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 11 Aug 2014 08:01:56 -0500 From: "Roque Gagliano (rogaglia)" To: "George, Wes" Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt Thread-Index: AQHPtWRtLqS7oCnR5UW98EhW5WcMMA== Date: Mon, 11 Aug 2014 13:01:55 +0000 Message-ID: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.37] Content-Type: multipart/alternative; boundary="_000_D4797FBC79D744788BBB2CD38E2AD2D7ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/MelwtWHEpOoO-7E2fHrDlrwdrTA Cc: "sidr@ietf.org" , Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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, 11 Aug 2014 13:02:01 -0000 --_000_D4797FBC79D744788BBB2CD38E2AD2D7ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Wes, Thanks for your message, I think it is always great to have a fresh view wh= en we are looking at new problems. I have some comments inline. Cheers! Roque On Aug 5, 2014, at 5:51 PM, "George, Wes" > wrote: On 8/4/14, 5:47 PM, "Sandra Murphy" > wrote: An invalid ROA does not necessarily mean an invalid route. If there is no other covering ROA, then a BGP route for that prefix becomes unknown, as Terry pointed out. If there is another ROA which covers the same prefix, then a route may be invalid -- if no covering ROA authorizes the ASN that the invalidated ROA mentions. WG] I'm once again bitten by an incomplete understanding of the way that the PKI interacts with the routing side. Sigh. That makes more sense, but since I have often volunteered to be "new guy who's not an RPKI expert" thus serving as the canary in the coal mine for finding the hidden gotchas like this, we have a very important detail here that may or may not be properly covered in our existing documents. I went poking through 6907, and it contains a useful definition for a covering ROA that seems to imply that an invalid ROA could technically still be considered a covering ROA, but for this: "For all of the use cases in this document, it is assumed that RPKI objects (e.g., resource certificates, ROAs) validate in accordance with [RFC6487] and [RFC6480]. In other words, we assume that corrupted RPKI objects, if any, have been detected and eliminated." So that text explicitly declares this case of invalid ROA and how to handle it out of scope for the scenarios discussed. Restating the combination of this text and your answer above, is it accurate to say that invalid ROAs are removed before the RP ever gets to the step where it checks to see if they are covering or matching, thus it is impossible for an invalid ROA to invalidate a route? Is that required by the standard, or simply an implementation convention that some or all of the existing RP software follows? (Roque) The answer resides in the definitions of VRPs-Validated ROA payloads which = is the information received by the BGP speakers. As its name states, the va= lidator server only sends VRPs that correspond to valid ROAs. So, you are r= ight that in the transition from ROAs to VRPs, the router has not knowledge= that there were some signed objects (not just ROAs) that failed the valida= tion process. This behaviour is document on RFC 6811: "The BGP speaker loads validated objects from the cache into local storage. The objects loaded have the content (IP address, prefix length, maximum length, origin AS number). We refer to such a locally stored object as a "Validated ROA Payload" or "VRP"." Terry's point is that as VRPs always correspond to valid ROAs, the problem = under discussion will, in the worse case, take you to a "not-found" state. I think that begs some further questions: Is there ever a case where we *want* an invalid ROA to translate to an invalid route, or do we *always* want to simply punt those from the system so that the routes they would have covered are tested only against any remaining valid ROAs? (Roque) There is the case of AS 0 (section 7.1.6 in RFC6907 and also in RFC 6483 BUT both Informati= onal documents). AS0 was thought as a solution to bogon prefixes or networks that are not me= ant to be public (military, banks, etc.) Do we ever see a need to treat an invalid ROA as a revoke? (Roque) I believe the current process of allowing to take the union of vali= d ROAs for a given prefix is the right strategy. It is consistent with the = "make before break" principle. Some examples are: - changing network ASes - networks with multiple origin ASes - ROA's EE certification roll-overs Is the behavior any different if the ROA was previously valid and unexpired, and suddenly becomes invalid vs if it was previously unknown and the first ROA that shows up is invalid? (Roque) You only send VRPs to the routers, which correspond to valid ROAs. = You notify the router of changes, including removals I'm quite sure that diving into this will also generate a bunch of unpleasant questions about tiebreaker behavior when both valid and invalid ROAs match or cover prefixes, so it may be simpler to just make it clear that this is the intended behavior, but I figured I'd pose the questions since that's what we seem to be having a fundamental misunderstanding about. (Roque) VRPs are always referring to valid ROAs. There is not "matching" wi= th invalid ROAs. The problem under discussion, IMO, is that in some specifi= c "corner cases" where ROAs may be invalidated due to some issues up in the= allocation hierarchy. I think that there are probably still cases during a transfer where if you get the order of operations wrong, in addition to the invalid ROA, you will have a second valid covering ROA that might not match what's being announced and thus a potentially invalid route. That's probably what needs to be enumerated in the validation-reconsidered draft as the problem with the biggest potential impact, even if it's secondary to the main failure mode where a bunch of routes just go to unknown status and temporarily lose the protection that origin validation is supposed to provide. (Roque) Agree to add to the document a "before" and "after" process for tra= nsfer as example. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --_000_D4797FBC79D744788BBB2CD38E2AD2D7ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <823C278C02B91B429CE4BF8F5458E7AD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi Wes,

Thanks for your message, I think it is always great to have a fresh vi= ew when we are looking at new problems.

I have some comments inline.

Cheers!
Roque

On Aug 5, 2014, at 5:51 PM, "George, Wes" <wesley.george@twcable.com> wrote:

On 8/4/14, 5:47 PM, "Sandra Murphy" <sandy@tislabs.com> wrote:

An invalid ROA does not necessarily mean an inval= id route.

If there is no other covering ROA, then a BGP route for that prefix
becomes unknown, as Terry pointed out.

If there is another ROA which covers the same prefix, then a route may be invalid -- if no covering ROA authorizes the ASN that the invalidated ROA mentions.

WG] I'm once again bitten by an incomplete understanding of the way that the PKI interacts with the routing side. Sigh. That makes more sense, but since I have often volunteered to be "new guy who's not an RPKI expert= "
thus serving as the canary in the coal mine for finding the hidden gotchas<= br> like this, we have a very important detail here that may or may not be
properly covered in our existing documents.

I went poking through 6907, and it contains a useful definition for a
covering ROA that seems to imply that an invalid ROA could technically
still be considered a covering ROA, but for this:
"For all of the use cases in this document, it is assumed that RPKI   objects (e.g., resource certificates, ROAs) validate in accorda= nce
  with [RFC6487] and [RFC6480].  In other words, we assume t= hat
  corrupted RPKI objects, if any, have been detected and eliminat= ed."
So that text explicitly declares this case of inv= alid ROA and how to
handle it out of scope for the scenarios discussed.

Restating the combination of this text and your answer above, is it
accurate to say that invalid ROAs are removed before the RP ever gets to the step where it checks to see if they are covering or matching, thus it is impossible for an invalid ROA to invalidate a route? Is that required by the standard, or simply an implementation convention that some or all of the existing RP software follows?

(Roque) 
The answer resides in the definitions of VRPs-Validated ROA payloads w= hich is the information received by the BGP speakers. As its name stat= es, the validator server only sends VRPs that correspond to valid ROAs. So,= you are right that in the transition from ROAs to VRPs, the router has not knowledge that there were some signe= d objects (not just ROAs) that failed the validation process. This behaviou= r is document on RFC 6811:

"The BGP speaker loads validated objects from the cache into loca= l
   storage.  The objects loaded have the content (IP=
 address, prefix
   length, maximum length, origin AS number).  We refer to such a
   locally stored object as a "Validated ROA Payload" or "VR=
P"."

Terry's point is that as VRPs always correspond to valid ROAs, the pro= blem under discussion will, in the worse case, take you to a "not-foun= d" state.


I think that begs some further questions: Is there ever a case where we
*want* an invalid ROA to translate to an invalid route, or do we *always* want to simply punt those from the system so that the routes they would
have covered are tested only against any remaining valid ROAs?

(Roque) There is the case of AS 0 (section 7.1.6 in RFC6907 and also in RFC 6483 BUT  both Informa= tional documents).

AS0 was thought as a solution to bogon prefixes or networks that are n= ot meant to be public (military, banks, etc.)

Do we ever
see a need to treat an invalid ROA as a revoke?

(Roque) I believe the current process of allowing to take the union of= valid ROAs for a given prefix is the right strategy. It is consistent with= the "make before break" principle.
Some examples are:
- chan= ging network ASes
- netw= orks with multiple origin ASes
- ROA'= s EE certification roll-overs

Is the behavior any
different if the ROA was previously valid and unexpired, and suddenly
becomes invalid vs if it was previously unknown and the first ROA that
shows up is invalid?

(Roque) You only send VRPs to the routers, which correspond to valid R= OAs. You notify the router of changes, including removals

I'm quite sure that diving into this will also generate a bunch of unpleasant questions about tiebreaker behavior when
both valid and invalid ROAs match or cover prefixes, so it may be simpler to just make it clear that this is the intended behavior, but I figured
I'd pose the questions since that's what we seem to be having a
fundamental misunderstanding about.

(Roque) VRPs are always referring to valid ROAs. There is not "ma= tching" with invalid ROAs. The problem under discussion, IMO, is that = in some specific "corner cases" where ROAs may be invalidated due= to some issues up in the allocation hierarchy.


I think that there are probably still cases during a transfer where if you<= br> get the order of operations wrong, in addition to the invalid ROA, you
will have a second valid covering ROA that might not match what's being
announced and thus a potentially invalid route.
That's probably what needs
to be enumerated in the validation-reconsidered draft as the problem with the biggest potential impact, even if it's secondary to the main failure mode where a bunch of routes just go to unknown status and temporarily
lose the protection that origin validation is supposed to provide.

(Roque) Agree to add to the document a "before" and "af= ter" process for transfer as example. 


Thanks
Wes George


This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mai= l, you are hereby notified that any dissemination, distribution, copying, o= r action taken in relation to the contents of and attachments to this E-mai= l is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the = sender immediately and permanently delete the original and any copy of this= E-mail and any printout.
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

--_000_D4797FBC79D744788BBB2CD38E2AD2D7ciscocom_-- From nobody Mon Aug 11 08:59:05 2014 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 96A841A068C for ; Mon, 11 Aug 2014 08:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 fTiJIjlB5Xe9 for ; Mon, 11 Aug 2014 08:59:03 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (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 CDECB1A0684 for ; Mon, 11 Aug 2014 08:59:02 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XGrzv-0006fF-Ad; Mon, 11 Aug 2014 17:59:01 +0200 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-177.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XGrzv-0006Qg-7O; Mon, 11 Aug 2014 17:58:59 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Tim Bruijnzeels In-Reply-To: Date: Mon, 11 Aug 2014 17:58:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <06ECFB67-7928-4860-8E1C-C661258E31DD@ripe.net> References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> To: Randy Bush X-Mailer: Apple Mail (2.1878.6) X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.6 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.7 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: 784d7acfe6559f2a0b602ec6519a071919fb1dc4ebec059ab1374dd2d1675935 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/DsDrh-SFWOfWWSMT42ExTam7_rU Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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, 11 Aug 2014 15:59:04 -0000 On 09 Aug 2014, at 04:42, Randy Bush wrote: >>>> The question was about why, in this effort, we are using 3779 >>>> validation rules >>> because we understand how they work formally from considerable >>> experience with PKIs. they are deployed and working today. >> Well ok. Where else are the 3779 rules used? >=20 > the validation for 3779 is essentially the same as for X.509, a rigid > hierarchy. =20 Personally I am not challenging this general approach. The *one* thing I (and I believe we..) challenge is whether the an = overclaimed resource should invalidate a complete certificate, instead = of invalidating just the resources at hand, but allowing the remainder. >>> the wg is considering an other validation process. it is still a = bit >>> wobbly, and the need for it is poorly motivated. if you remember, i >>> advocated looking at this as a work item, and came up with the one >>> rather subtle motivation for it. >> I=92m not seeing the relevance of this history lesson to the question >> that was asked. How does this relate to the technical reasons of why >> we are using 3779 rules? >=20 > because they are working. you are proposing a change to a deployed > rfc. what is the motivation for the change? be technically explicit. Resource certificates are always evaluated in context. Under RFC3779 we = accept the resources listed for the trust anchor as-is, but for = everything down the chain we insist that *everything* is also held by = the parent. I.e. we know exactly which resources we are willing to = accept. So we do not believe the listed resources at face value. I understand that conceptually this is an attractive simple model. = However I believe that are reasons why certificates can end up = overclaiming, and *importantly* this is not always something that a CA = has full control over. Essentially I see two causes, that can be caused by various reasons: 1 =3D the parent certificate is shrunk and published before the, now = overclaiming, certificate is shrunk and re-published 2 =3D the certificate is grown and republished, before the grown parent = certificate is republished, so it looks overclaiming Some possible causes, there may be more: The following two we may be able to mitigate technically, because we are = dealing with co-operating parties: @1 There is a mis-timing in certificate shrinking in a transfer = between co-operating parties. @2 There is a mis-timing in the parent publishing a cert with extended = resource, and issuing it to the child, and the child using those = resources in turn. But this is the one that has me scared. It is not the issuing CA being = sloppy, it=92s a problem between them and *their* parent: @1 The *grand*-parent shrinks the *parent* certificate without the = parent knowing about this, and some of these resources appear on the, = now overclaiming, child certificate. The grand-parent and parent are not = involved in an active transfer process. They may not agree that the = resource in question should be removed, or the grand-parent may have = shrunk these resources in error. By rejecting the overclaiming child certificate completely I think we = are being too harsh, or pedantic even. We know better, so we are just = not going to trust this one. But.. there is a very real possibility that = we actually *do* know better than the issuing CA at this point. So, what = exactly is the problem with accepting the remaining resources? i.e. the = intersection between the parent certificate=92s resources and this = certificate. We know the context, this evaluation is very easy and = well-defined. If the CA really intended that the remaining resources = should not be tied to the certificate, they would have revoked. If the = grand-parent really intended that those resources should not be = certified anymore, they would have removed them as well. > the point of the history lesson of the rirs blocking the definition = and > documentation of transfer is that it seems to be the only serious = reason > for the change those very same rirs are proposing. so, if you want = your > proposal to change rfced running code to be taken seriously, you had > best document it technically, not just throw perjoratives and = hyperbole. I think a formal specification for transfers can mitigate the problem of = transfers between co-operative CAs, but this can not mitigate errors. But, more importantly our transfer policies are set in the address = policy working group, and our implementation is based on the directives = that we get from our community there. Other RIRs have similar, but = slightly different policies. The =91rules=92 regarding these transfers = can be changed at any time. As an RIR employee I feel a lot of = reluctance against engaging in a technical definition of a transfer, as = it can be perceived to compete with our community process.=20 > i just want clear and well-understood technical reasons for a > change to deployed running documented code that seems to be working. I hope that the third case above (CA unaware that its own certificate = has shrunk) made my motivations more clear. I understand that changing running code is a pain, but I don=92t think = it=92s impossible. We have running code that warns about overclaiming, = but accepts remaining. Tim From nobody Mon Aug 11 10:41:46 2014 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 28D2A1A0478 for ; Mon, 11 Aug 2014 10:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 rRijBK-vdo8C for ; Mon, 11 Aug 2014 10:41:42 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 577B61A045E for ; Mon, 11 Aug 2014 10:41:42 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 13708213708; Mon, 11 Aug 2014 13:41:42 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 6114C213701; Mon, 11 Aug 2014 13:41:41 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 11 Aug 2014 13:42:16 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Mon, 11 Aug 2014 13:41:40 -0400 From: Andy Newton To: Randy Bush Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt Thread-Index: AQHPnD4MWZPJUx8QpU+h2rFbrnAOgJuuUuIAgAFi9wCAADDNAIAAG7gAgAASbgCAAQkngIAARcuAgAAYJwCACYOYgIAHti8AgAA4cYCAAAsogIABK/gAgAMjF4CAADFtgIAAFnKAgABxd4CABB/sgA== Date: Mon, 11 Aug 2014 17:41:39 +0000 Message-ID: <3605A027-0230-4C3A-BD4B-4126B6091825@arin.net> References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.87] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9818DA56A36E8647A4FF7ED1E95CAFC0@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/NxsJE6ItdtYsnIQIcIzIQ2HaUsI Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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, 11 Aug 2014 17:41:44 -0000 On Aug 8, 2014, at 10:42 PM, Randy Bush wrote: >>>> The question was about why, in this effort, we are using 3779 >>>> validation rules >>> because we understand how they work formally from considerable >>> experience with PKIs. they are deployed and working today. >> Well ok. Where else are the 3779 rules used? >=20 > the validation for 3779 is essentially the same as for X.509, a rigid > hierarchy. some do not like different aspects of that rigidity, i am > among them, but for different aspects than this one. Ah. I think I see the disconnect. The validity of a certificate with 3779 e= xtensions is covered by section 2.3 and 3.3 of 3779. Those are the rules fo= r answering =93Is this certificate valid?=94 However, what use is that ques= tion by itself? Isn=92t a better question, =93Can this IP address be valida= ted with this certificate?=94 It is a matter of context, and the current va= lidation rules lack context. If a certificate covers 192.0.2.0/24 and 198.51.100.0/24 yet its parent onl= y covers 192.0.2.0/24, that certificate is invalid even though 192.0.2.0/24= has a path of validity. Why? In the context of =93Is 192.0.2.0/24 valid wi= th this certificate?=94, why can=92t we say yes? >>> to paraphrase, C=92mon Andy. You're better than this. >> Imitation is the sincerest form of flattery. I=92m now thinking about >> shaving off my beard. ;) >=20 > not likely. the last time i was beardless jack kennedy was president. > i do not change running beard without a sound technical reason. otoh, > if you can document how i can transfer to a 27 year old body, we would > likely have a deal. Can we compromise with a zombie-JFK? -andy= From nobody Mon Aug 11 11:02:35 2014 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 1606C1A065E for ; Mon, 11 Aug 2014 11:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 w2MSnhWqHXHZ for ; Mon, 11 Aug 2014 11:02:31 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 85AA71A05D3 for ; Mon, 11 Aug 2014 11:02:31 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 441F0213715; Mon, 11 Aug 2014 14:02:31 -0400 (EDT) Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 9229E213724; Mon, 11 Aug 2014 14:02:30 -0400 (EDT) Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 11 Aug 2014 14:03:05 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Mon, 11 Aug 2014 14:02:29 -0400 From: Andy Newton To: Sandra Murphy Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt Thread-Index: AQHPnD4MWZPJUx8QpU+h2rFbrnAOgJuuUuIAgAFi9wCAADDNAIAAG7gAgAASbgCAAQkngIAARcuAgAAYJwCACYOYgIAHti8AgAA4cYCAAAsogIABK/gAgAMjF4CAACivgIAAFG0AgAASSACAAA7/AIAAEPyAgARvtYA= Date: Mon, 11 Aug 2014 18:02:29 +0000 Message-ID: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> <0C1A79F7-5536-4031-A3E1-C0EC582225D7@tislabs.com> <072C1DD2-658A-42A1-B44C-627387C27842@tislabs.com> In-Reply-To: <072C1DD2-658A-42A1-B44C-627387C27842@tislabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.87] Content-Type: text/plain; charset="Windows-1252" Content-ID: <192F3EF2F8EE9C43842347B90074C4F0@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/5Om2wbdmd2BzRFCz2T8P1CQ90Hw Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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, 11 Aug 2014 18:02:33 -0000 On Aug 8, 2014, at 6:17 PM, Sandra Murphy wrote: >> I=92m fine with not characterizing motives and historical context. Just = following your lead. :) >=20 > I did not mention motives, I mentioned motivations, as in the requirement= s that drove the design. That sounds like splitting hairs. > I think I answered that. The RPKI was designed for the prefix allocation = system. In the prefix allocation system, one can allocate only from the all= ocation one holds. 3779 also was designed to follow the prefix allocation = system and its rules enforce that allocation behavior. It provided the fea= tures a certification of the prefix allocation system needed, so it was ado= pted. Except 3779 goes further, in that if a certificate ever claims more than wh= at has been allocated then NONE of its allocations are valid. > I was attempting to point out that the only other existing system with an= authorization model also follows the same encompassing rule. Again, the e= ncompassing rule is derived from the behavior of the prefix allocation syst= em. Which seems to be an answer far afield from =93where else is 3779 used?=94 -andy From nobody Tue Aug 12 17:26:51 2014 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 50F211A0AE4 for ; Tue, 12 Aug 2014 17:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 Cc_BxDaUxs3P for ; Tue, 12 Aug 2014 17:26:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD0E1A0A8B for ; Tue, 12 Aug 2014 17:26:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C7BF8180015; Tue, 12 Aug 2014 17:25:01 -0700 (PDT) To: gih@apnic.net, ggm@apnic.net, robertl@apnic.net, akatlas@gmail.com, adrian@olddog.co.uk, morrowc@ops-netman.net, sandy@tislabs.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140813002501.C7BF8180015@rfc-editor.org> Date: Tue, 12 Aug 2014 17:25:01 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/GApeMh5I1MLr9D11TIvXAZ3pX_A Cc: rfc-editor@rfc-editor.org, sidr@ietf.org Subject: [sidr] [Technical Errata Reported] RFC6487 (4080) 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 Aug 2014 00:26:51 -0000 The following errata report has been submitted for RFC6487, "A Profile for X.509 PKIX Resource Certificates". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6487&eid=4080 -------------------------------------- Type: Technical Reported by: Sean Turner Section: 6.1.1 Original Text ------------- This field MAY be omitted. If present, the value of this field SHOULD be empty (i.e., NULL), in which case the CA MUST generate a subject name that is unique in the context of certificates issued by this CA. This field is allowed to be non-empty only for a re-key/reissuance request, and only if the CA has adopted a policy (in its Certificate Practice Statement (CPS)) that permits reuse of names in these circumstances. Corrected Text -------------- This field SHOULD be empty (i.e., NULL), in which case the CA MUST generate a subject name that is unique in the context of certificates issued by this CA. This field is allowed to be non-empty only for a re-key/reissuance request, and only if the CA has adopted a policy (in its Certificate Practice Statement (CPS)) that permits reuse of names in these circumstances. Notes ----- Submitted after consultation with the responsible AD and WG chairs. The subject field included in the PKCS#10 request can't be omitted because the ASN.1 in RFC 2986 doesn’t allow subject to be omitted - there’s no “OPTIONAL” in the ASN.1: CertificationRequestInfo ::= SEQUENCE { version INTEGER { v1(0) } (v1,...), subject Name, subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }}, attributes [0] Attributes{{ CRIAttributes }} } In other words, four fields are included in every certificate request. If there’s no subject field it’s a NULL (see RFC5280 for omitting subjects) and if there’s no attributes it’s an empty sequence. version and subjectPKInfo (subject public key information) are always present. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6487 (draft-ietf-sidr-res-certs-22) -------------------------------------- Title : A Profile for X.509 PKIX Resource Certificates Publication Date : February 2012 Author(s) : G. Huston, G. Michaelson, R. Loomans Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Aug 12 17:44:47 2014 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 42DA01A6F52; Tue, 12 Aug 2014 17:44:44 -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 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 iaakGJH-2nj6; Tue, 12 Aug 2014 17:44:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5940B1A6F57; Tue, 12 Aug 2014 17:44:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140813004442.10560.45299.idtracker@ietfa.amsl.com> Date: Tue, 12 Aug 2014 17:44:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/uSyJ0PI3nRqMf-krnrUjG9hwQDs Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-08.txt 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: Wed, 13 Aug 2014 00:44:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests Authors : Mark Reynolds Sean Turner Steve Kent Filename : draft-ietf-sidr-bgpsec-pki-profiles-08.txt Pages : 13 Date : 2014-08-12 Abstract: This document defines a standard profile for X.509 certificates for the purposes of supporting 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 a critical component for the proper operation of the Internet as a whole. The BGPSEC protocol is under development as a component to address the requirement to provide security for the BGP protocol. The goal of BGPSEC is to design a protocol for full AS path validation based on the use of strong cryptographic primitives. The End-Entity (EE) certificates specified by this profile are issued under Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificates, containing the AS Identifier Delegation extension, to routers within the Autonomous System (AS). The certificate asserts that the router(s) holding the private key are authorized to send out secure route advertisements on behalf of the specified AS. This document also profiles the Certificate Revocation List (CRL), profiles the format of certification requests, and specifies Relying Party certificate path validation procedures. The document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (RFC 6487). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 12 17:47:43 2014 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 55C101A6F6E for ; Tue, 12 Aug 2014 17:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.107 X-Spam-Level: X-Spam-Status: No, score=0.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.674, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 WMWERR1XL1xT for ; Tue, 12 Aug 2014 17:47:41 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.56.150.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21AC71A00F0 for ; Tue, 12 Aug 2014 17:47:41 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 5D8C8E33BA819; Tue, 12 Aug 2014 19:47:40 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 4AF80E33BA7C3 for ; Tue, 12 Aug 2014 19:47:40 -0500 (CDT) Received: from [96.231.227.95] (port=59005 helo=192.168.1.6) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XHMj5-0008QZ-Ox for sidr@ietf.org; Tue, 12 Aug 2014 19:47:39 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <20140813004442.10560.45299.idtracker@ietfa.amsl.com> Date: Tue, 12 Aug 2014 20:47:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140813004442.10560.45299.idtracker@ietfa.amsl.com> To: sidr wg list X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.227.95 X-Exim-ID: 1XHMj5-0008QZ-Ox X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.6) [96.231.227.95]:59005 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/nC8ymb5fEC9ZAcxsYs1HzTazHA4 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-08.txt 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 Aug 2014 00:47:42 -0000 This version incorporates the change discussed at IETF 90 - namely = include one and only one AS in the certificate. The working version is also available at: https://github.com/seanturner/draft-ietf-sidr-bgpsec-pki-profiles spt On Aug 12, 2014, at 20:44, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >=20 > Title : A Profile for BGPSEC Router Certificates, = Certificate Revocation Lists, and Certification Requests > Authors : Mark Reynolds > Sean Turner > Steve Kent > Filename : draft-ietf-sidr-bgpsec-pki-profiles-08.txt > Pages : 13 > Date : 2014-08-12 >=20 > Abstract: > This document defines a standard profile for X.509 certificates for > the purposes of supporting 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 a critical component for the = proper > operation of the Internet as a whole. The BGPSEC protocol is under > development as a component to address the requirement to provide > security for the BGP protocol. The goal of BGPSEC is to design a > protocol for full AS path validation based on the use of strong > cryptographic primitives. The End-Entity (EE) certificates = specified > by this profile are issued under Resource Public Key Infrastructure > (RPKI) Certification Authority (CA) certificates, containing the AS > Identifier Delegation extension, to routers within the Autonomous > System (AS). The certificate asserts that the router(s) holding the > private key are authorized to send out secure route advertisements = on > behalf of the specified AS. This document also profiles the > Certificate Revocation List (CRL), profiles the format of > certification requests, and specifies Relying Party certificate path > validation procedures. The document extends the RPKI; therefore, > this documents updates the RPKI Resource Certificates Profile (RFC > 6487). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-08 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-pki-profiles-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Aug 12 19:07:07 2014 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 2CBBB1A6FAC for ; Tue, 12 Aug 2014 19:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 pu8QbLFlJZcv for ; Tue, 12 Aug 2014 19:07:00 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (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 1A8611A6F9F for ; Tue, 12 Aug 2014 19:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=kk6gfLUiDcy24uWCDMbwzBhL3azAbztekS7FAb8xKak=; b=IATRrFgLqec263Cv5HtMf9zf+vlbdksm6f8gMTqhHG4HIMZMnr4q34NQPwpbfFxd4McI/Vt+A6pv7 iuknlFSy6SBMrtmdzf6ZVLZ5aORe5pDSY6GutJ35nf9mObAJp8r5VtmFckiax1Oh63TwsvkeTde71Z iPHT35EVUEuVyVcs= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Wed, 13 Aug 2014 12:06:48 +1000 (EST) Received: from app-svc-syd.canberra.aarnet.edu.au (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 13 Aug 2014 12:06:55 +1000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Geoff Huston In-Reply-To: <20140813002501.C7BF8180015@rfc-editor.org> Date: Wed, 13 Aug 2014 12:06:53 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140813002501.C7BF8180015@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/RSmQF0AUtTo8-a0PDikiMLjJ_Ig Cc: sidr@ietf.org, morrowc@ops-netman.net, robertl@apnic.net, sandy@tislabs.com, George Michaelson Subject: Re: [sidr] [Technical Errata Reported] RFC6487 (4080) 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 Aug 2014 02:07:03 -0000 I support verification of this Errata Report. Geoff On 13 Aug 2014, at 10:25 am, RFC Errata System = wrote: > The following errata report has been submitted for RFC6487, > "A Profile for X.509 PKIX Resource Certificates". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6487&eid=3D4080 >=20 > -------------------------------------- > Type: Technical > Reported by: Sean Turner >=20 > Section: 6.1.1 >=20 > Original Text > ------------- > This field MAY be omitted. If present, the value of this field > SHOULD be empty (i.e., NULL), in which case the CA MUST > generate a subject name that is unique in the context of > certificates issued by this CA. This field is allowed to be > non-empty only for a re-key/reissuance request, and only if the > CA has adopted a policy (in its Certificate Practice Statement > (CPS)) that permits reuse of names in these circumstances. >=20 > Corrected Text > -------------- > This field > SHOULD be empty (i.e., NULL), in which case the CA MUST > generate a subject name that is unique in the context of > certificates issued by this CA. This field is allowed to be > non-empty only for a re-key/reissuance request, and only if the > CA has adopted a policy (in its Certificate Practice Statement > (CPS)) that permits reuse of names in these circumstances. >=20 >=20 >=20 > Notes > ----- > Submitted after consultation with the responsible AD and WG chairs. >=20 > The subject field included in the PKCS#10 request can't be omitted = because the ASN.1 in RFC 2986 doesn=92t allow subject to be omitted - = there=92s no =93OPTIONAL=94 in the ASN.1: >=20 > CertificationRequestInfo ::=3D SEQUENCE { > version INTEGER { v1(0) } (v1,...), > subject Name, > subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }}, > attributes [0] Attributes{{ CRIAttributes }} > } >=20 > In other words, four fields are included in every certificate request. = If there=92s no subject field it=92s a NULL (see RFC5280 for omitting = subjects) and if there=92s no attributes it=92s an empty sequence. = version and subjectPKInfo (subject public key information) are always = present. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6487 (draft-ietf-sidr-res-certs-22) > -------------------------------------- > Title : A Profile for X.509 PKIX Resource Certificates > Publication Date : February 2012 > Author(s) : G. Huston, G. Michaelson, R. Loomans > Category : PROPOSED STANDARD > Source : Secure Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 From nobody Wed Aug 13 09:42:41 2014 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 8E15B1A00C6 for ; Wed, 13 Aug 2014 09:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 VtUxHtYIqArY for ; Wed, 13 Aug 2014 09:42:31 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455BD1A091E for ; Wed, 13 Aug 2014 09:42:31 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 827B228B005B; Wed, 13 Aug 2014 12:42:30 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 63EC31F8032; Wed, 13 Aug 2014 12:42:30 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2509FEDE-7750-4679-833B-34E703B74157"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Wed, 13 Aug 2014 12:42:29 -0400 Message-Id: <4556FA63-A6FD-471B-93FD-51D748C94EE8@tislabs.com> References: <20140813004442.10560.45299.idtracker@ietfa.amsl.com> To: Sean Turner X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/OC-TdCtZskP0YtDXLt8yAsSh9pw Cc: sidr wg list , Sandra Murphy Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-08.txt 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 Aug 2014 16:42:38 -0000 --Apple-Mail=_2509FEDE-7750-4679-833B-34E703B74157 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii speaking as regular ol' member A question about wording. I understand the wording change in 3.1.1 (used to be 3.1.1.1) that = results from the change from multiple ASs in a cert to a single AS in a = cert. But there is also a wording change having to do with multiple routers = sharing the same key pair. The wording went from: If the same certificate is issued to = more than one router (hence the private key is shared among these routers), the choice of the router ID used in this name is at the discretion of the Issuer. to: If more than one = certificate for an AS is issued (i.e., more than one router gets a certificate for the AS and hence the private key is shared among more than one router), the choice of the router ID used in Subject name is at the discretion of the Issuer. I don't understand the new wording. If all routers in an AS have = different keys, then there would be multiple certificates issued for the = AS, but no sharing of keys and no confusion over the router ID to be = used in each router's cert. Right? Apologies if I'm just not parsing the new sentence correctly. The = previous wording was fine with me. [The certificate request format does not include the subject name = anyway, so it looks to me like the subject name is ALWAYS at the = discretion of the issuer. No?) --Sandy, speaking as regular ol' member On Aug 12, 2014, at 8:47 PM, Sean Turner wrote: > This version incorporates the change discussed at IETF 90 - namely = include one and only one AS in the certificate. >=20 > The working version is also available at: > https://github.com/seanturner/draft-ietf-sidr-bgpsec-pki-profiles >=20 > spt >=20 > On Aug 12, 2014, at 20:44, internet-drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >>=20 >> Title : A Profile for BGPSEC Router Certificates, = Certificate Revocation Lists, and Certification Requests >> Authors : Mark Reynolds >> Sean Turner >> Steve Kent >> Filename : draft-ietf-sidr-bgpsec-pki-profiles-08.txt >> Pages : 13 >> Date : 2014-08-12 >>=20 >> Abstract: >> This document defines a standard profile for X.509 certificates for >> the purposes of supporting 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 a critical component for the = proper >> operation of the Internet as a whole. The BGPSEC protocol is under >> development as a component to address the requirement to provide >> security for the BGP protocol. The goal of BGPSEC is to design a >> protocol for full AS path validation based on the use of strong >> cryptographic primitives. The End-Entity (EE) certificates = specified >> by this profile are issued under Resource Public Key Infrastructure >> (RPKI) Certification Authority (CA) certificates, containing the AS >> Identifier Delegation extension, to routers within the Autonomous >> System (AS). The certificate asserts that the router(s) holding the >> private key are authorized to send out secure route advertisements = on >> behalf of the specified AS. This document also profiles the >> Certificate Revocation List (CRL), profiles the format of >> certification requests, and specifies Relying Party certificate path >> validation procedures. The document extends the RPKI; therefore, >> this documents updates the RPKI Resource Certificates Profile (RFC >> 6487). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-08 >>=20 >> A diff from the previous version is available at: >> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-pki-profiles-08 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_2509FEDE-7750-4679-833B-34E703B74157 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT65V1AAoJEHplpQeet0IZe5IP/jGZzZf0NL6iLjQnEsc851AW t8Wol3yG+2/slaOSxLk8GS7uQkIZgupEWvCdSLzFrBbUDQBgGUbnuEev08v7fDgG imej63D1/VaTF7BtuMnnmin0lTNoU1zTwI1y05CyUAQ+avbyRkMXk6OVog2vG3Sd aVSOwY/z3cT6fwhtNkQk4qnMRaV5duc3mSP2CIvT0Q9DfaLLXDidcolCBMMW0gss RdqTlAUb/+wqY59YePGrRwUojyDqEEh+myj1tfe8kfRiFMBXYgwEfU+mw6g9sxfC eOV4pypMAFxEe7rQHQl30dTGbSSRWex49h28oqRRAX4jMEV41RfjGICzZe6jhaJf s5uUYAOxZg5mckqJ9CsSrOx3eSAOz696TtkTzvzH+RFwdC660+3n1gbjWQRTClf9 vpWlmua2Ii46if0IUvw8r9V9+uRrD5a+3cU3LTlaMDeRizRA1y2JHmU62fYIfY19 WYNIuUbhBqoDiduk2+A2lWmN8ftFZqFFpUjZF6apO0vKXMpcWTi/+Go5XeTZ83AZ OcFnira0cUgKPSSBR+sfxzJJqvP40VY7ODsyCg6QkVrsL1Al++lR9++nbyhrAtN9 TEwuw3WaTlz8QQe5BQxQA67SR0IdhxwR6rtKwW5y+yRj3vC+ShlG0jmwJbuDCFtS /0Q6OK+lzEsFF2lN38d6 =yyCy -----END PGP SIGNATURE----- --Apple-Mail=_2509FEDE-7750-4679-833B-34E703B74157-- From nobody Thu Aug 14 07:12:26 2014 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 40E351A0B73 for ; Thu, 14 Aug 2014 07:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668, 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 IhCmSmiPKgFS for ; Thu, 14 Aug 2014 07:12:22 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (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 6E1951A0B72 for ; Thu, 14 Aug 2014 07:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:from:to:subject:thread-topic:thread-index:date:message-id: references:in-reply-to:accept-language:content-language:x-ms-has-attach: x-ms-tnef-correlator:x-originating-ip:content-type:content-transfer-encoding: mime-version; bh=jXtKtx4HdnOflmCBVcrMwkHIZrEwdwhvYsZDp1Ph+cE=; b=cQObKR6Inll6lS1NW09nt6NE7N0lnHA9Ivh/8L9OouDpdEZdv1935QPSoZx1Xew+2u8Rli7BP8q7/ XsGSGf/KaUzF2JX4cXOgHzYIK79Q1y086H3Nj76g9GhcvXLv6y5a/YJeLedMev/QOgKfGfI4GgiyMh C6uzZlUhDlg6ASCA= Received: from iamda3.org.apnic.net (unknown [203.119.101.249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Fri, 15 Aug 2014 00:11:59 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by iamda3.org.apnic.net ([fe80::e195:c0e8:e814:db75%15]) with mapi id 14.01.0218.012; Fri, 15 Aug 2014 00:12:17 +1000 From: Byron Ellacott To: Randy Bush , "sidr@ietf.org" Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt Thread-Index: AQHPnD4HqbRCfUo98U+dXEdIyh/oh5utaDEAgAFi9wCAADDNAIAAG7cAgAASbwCAAMYUgIAAiN6AgAAYJwCACYOXgIAHti8AgAA4coCAAAsogIABK/cAgAMjFoCAADFvgIAAFm+AgABxeYCACTVBnA== Date: Thu, 14 Aug 2014 14:11:40 +0000 Message-ID: References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <53D151F0.80808@bbn.com> <53D178A6.7060502@bbn.com> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> , In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:dd8:9:2::101:249] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/rK16w1-mJkapphKL1VrkE-Cj4uk Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt 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 Aug 2014 14:12:24 -0000 Randy,=0A= =0A= > the point of the history lesson of the rirs blocking the definition and= =0A= > documentation of transfer is that it seems to be the only serious reason= =0A= > for the change those very same rirs are proposing. so, if you want your= =0A= > proposal to change rfced running code to be taken seriously, you had=0A= > best document it technically, not just throw perjoratives and hyperbole.= =0A= =0A= Transfer for APNIC is defined and documented:=0A= =0A= http://www.apnic.net/policy/transfer-policy=0A= =0A= =85 which you are no doubt familiar with, having contributed actively to it= s development. The point is resource transfer is documented as a number re= gistry policy process, not as a technical process. Of course, the RPKI ver= y conveniently requires that CA certification actions follow registry actio= ns, so when one uses an RIR's policy for transfer to enact a transfer, cert= ificates are updated without any extra technical process needed.=0A= =0A= The RPKI, as Sandy has indirectly suggested, is a view of the resource allo= cation hierarchy. Defining technical processes for changing the contents o= f the RPKI does not make sense, as the RPKI does not change, the resource a= llocation hierarchy does.=0A= =0A= If 'make before break' semantics are important when a certificate is revoke= d and reissued following a registry action, the WG could certainly produce = something there - perhaps 4.5.9 of the CPS draft is a possible place to do = this? As a bonus, addressing the consequences of "partial revocation" (RFC= 6484 4.9.1 requires revoke+reissue to remove some INRs from a certificate, = which is a hack around the all-or-nothing nature of 3779 validation) also d= eals with returns, exchanges, and plain old human or software error.=0A= =0A= Assuming, of course, that transient certificate errors are a problem that w= e should avoid :-)=0A= =0A= -- =0A= bje, speaking as an individual= From nobody Thu Aug 14 08:49:59 2014 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 7A5B31A07CE; Thu, 14 Aug 2014 08:49:57 -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 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 nvx_WYT42OF3; Thu, 14 Aug 2014 08:49:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 977F71A081C; Thu, 14 Aug 2014 08:49:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140814154952.12284.60127.idtracker@ietfa.amsl.com> Date: Thu, 14 Aug 2014 08:49:52 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/j34mYbNcTFRyFrkSXYO0RB_rIX4 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Protocol Action: 'Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)' to Best Current Practice (draft-ietf-sidr-cps-04.txt) 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: Thu, 14 Aug 2014 15:49:57 -0000 The IESG has approved the following document: - 'Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)' (draft-ietf-sidr-cps-04.txt) as Best Current Practice This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Alia Atlas and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-cps/ Technical Summary This document contains a template to be used for creating a Certification Practice Statement (CPS) for an Organization that is part of the Resource Public Key Infrastructure (RPKI), e.g., a resource allocation registry or an ISP. Working Group Summary This document is a simple template to be used by a relevant CA in the SIDR system. It is based off: RFC 3647, and is by and large straight forward. There was no significant heated discussion on this document in the WG. Document Quality Since this is a template, which is based on RFC 3647, there are no more 'implementations'. Personnel shephard: chris morrow AD: Alia Atlas From nobody Fri Aug 15 08:23:09 2014 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 5E1A11A0205 for ; Fri, 15 Aug 2014 08:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 BeHjH2B06wsM for ; Fri, 15 Aug 2014 08:23:05 -0700 (PDT) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by ietfa.amsl.com (Postfix) with ESMTP id DA20B1A0B0B for ; Fri, 15 Aug 2014 08:23:05 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id E964746B8C for ; Fri, 15 Aug 2014 11:23:04 -0400 (EDT) Received: from fledge.watson.org (weiler@localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.8/8.14.8) with ESMTP id s7FFN4tx074348 for ; Fri, 15 Aug 2014 11:23:04 -0400 (EDT) (envelope-from sidr-secretary@samweiler.com) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.8/8.14.8/Submit) with ESMTP id s7FFN4FT074344 for ; Fri, 15 Aug 2014 11:23:04 -0400 (EDT) (envelope-from sidr-secretary@samweiler.com) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 15 Aug 2014 11:23:04 -0400 (EDT) From: SIDR Secretary X-X-Sender: weiler@fledge.watson.org To: sidr@ietf.org Message-ID: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (fledge.watson.org [127.0.0.1]); Fri, 15 Aug 2014 11:23:04 -0400 (EDT) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/WNKi9OmdC0Cj5Duhm1qYxOOmtd0 Subject: [sidr] Draft IETF90 Toronto minutes posted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sidr-chairs@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 15:23:07 -0000 Draft minutes from the Toronto meeting have been posted. Please send corrections to the chairs. Many thanks to Matt Lepinski for scribing and Wes George for jabber scribing. Draft minutes: http://www.ietf.org/proceedings/90/minutes/minutes-90-sidr Jabber log: http://www.ietf.org/jabber/logs/sidr/2014-07-25.html Audio: http://www.ietf.org/audio/ietf90/ietf90-territories-20140725-0900-am1.mp3 -- Sam From nobody Thu Aug 28 07:46:10 2014 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 ABA6E1A6FEB for ; Thu, 28 Aug 2014 07:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADULT2=1.474, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-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 H8QYOPsCEHXN for ; Thu, 28 Aug 2014 07:46:06 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C091A6FEE for ; Thu, 28 Aug 2014 07:46:01 -0700 (PDT) Received: from donkey.her.corp.google.com (unknown [72.14.227.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 8A7DA88004C; Thu, 28 Aug 2014 14:46:00 +0000 (UTC) Message-ID: <53FF40A8.5020100@ops-netman.net> Date: Thu, 28 Aug 2014 10:46:00 -0400 From: Chris Morrow User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "sidr-chairs@tools.ietf.org" , "sidr-ads@tools.ietf.org" , "sidr@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/NWQglfqzNfykBAVtiC9Rq6eQwS8 Subject: [sidr] WGLC - draft-ietf-sidr-as-migration 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, 28 Aug 2014 14:46:06 -0000 Howdy SIDR folken, It's time again to dust off your spectacles and dive into a wonderous world of 'potential RFC' reading material!! It'd be great if we could start this WGLC today: 8/28/2014 or August 28 2014 or the 240th day of this year 2014 and end it in 2 weeks time on: 9/11/2014 September 11, 2014 the 254th day of this year 2014 for the draft in the subject line: draft-ietf-sidr-as-migration the abstract of which is copied herein for your convenience: "This draft discusses considerations and methods for supporting and securing a common method for AS-Migration within the BGPSec protocol." This document's pair is in IDR WGLC at this time as well, that document is: happy reading and please send comments/concerns/adulation to the list. -chris wg-co-chair From nobody Fri Aug 29 09:32:38 2014 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 B45A11A05D1; Fri, 29 Aug 2014 09:32:35 -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 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 XBoaJ2lHCUFo; Fri, 29 Aug 2014 09:32:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 522791A0654; Fri, 29 Aug 2014 09:32:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140829163233.27054.73822.idtracker@ietfa.amsl.com> Date: Fri, 29 Aug 2014 09:32:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/hZ57pjgJZQ6rC9a0wW40WBTJB0Y Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-rfc6810-bis-02.txt 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 Aug 2014 16:32:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The Resource Public Key Infrastructure (RPKI) to Router Protocol Authors : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-rfc6810-bis-02.txt Pages : 30 Date : 2014-08-29 Abstract: 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 validated prefix origin data and router keys to routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-rtr-rfc6810-bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 29 09:55:00 2014 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 6AAEF1A0682 for ; Fri, 29 Aug 2014 09:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 JI5t1v6V9_-G for ; Fri, 29 Aug 2014 09:54:57 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EACB01A0675 for ; Fri, 29 Aug 2014 09:54:56 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-24-34-34-101.hsd1.ma.comcast.net [24.34.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 154083A574 for ; Fri, 29 Aug 2014 16:54:54 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 066DC11762B5 for ; Fri, 29 Aug 2014 12:55:24 -0400 (EDT) Date: Fri, 29 Aug 2014 12:55:24 -0400 From: Rob Austein To: sidr@ietf.org References: <20140829163233.27054.73822.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20140829165525.066DC11762B5@minas-ithil.hactrn.net> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/0lXUUVz9fMheRJu5DYYpnqalXzU Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-rfc6810-bis-02.txt 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: Fri, 29 Aug 2014 16:54:58 -0000 This revision fixes some minor textual issues that came up during implementation and review by a people other than the I-D authors (thanks, rtrlib team!). The one protocol change (also minor) is that the rtrlib team convinced us to lower the minimum allowed values for the Refresh and Retry timers to one second. While we don't think it likely that anybody would really want to configure a cache that way, it's a local matter: if I choose to configure my cache to tell my routers to beat up my cache server that often, it's really nobody else's business. This revision addresses all known outstanding issues for this I-D. As mentioned in Toronto, this I-D is on the critical path for BGPsec, because of the Router Key PDU. We've been holding this back from WGLC because we wanted a second client-side implementation, but we have that now, so we will be sending a WGLC request to the WG chairs.